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(54) Precede de surveillance d'une pluralite de types d'objets d'une pluralite de noeuds a partir 
d'un noeud d 'ad ministration dans un systeme informatlque 

(57) La presente invention concerne un precede de 
surveillance d'une pluralite de types d'objets sur une 
pluralite de noeuds (N1, N2, Nn) connprenant un 
noeud d'administration (MN) dans un systenne infornna- 
tique. Ce procede est rennarquable en ce que, la sur- 
veillance est conflguree puis diffusee de nnaniere filtree 
a partir du noeud d'adnninistration (MN) vers des agents 
autonomes (SAA), un agent autononne etant installe sur 
chaque noeud a surveiller pour, en offrant une correla- 
tion intertype, soit trailer au plus pres les differents types 
d'objets ou ensemble d'objets d'un domaine appele ob- 
jet global defini de maniere generique, soit remonterdes 
informations a visualiser vers interface graphique du 
noeud d'administration, chaque agent comportant une 
pluralite de modules specifiques (SM1, SM2, SMn) 
propres aux differents types d'objets ou a un domaine 
particulier, chaque module specifique mesurant des pa- 
rametres statiques et dynamiques, particuliers au type 
d'objet qu'il surveille et collectant lesdites mesures, tes- 
tant des conditions sur lesdits parametres relativement 
a des seuils predefinis et declenchant eventuellement 
des actions associees auxdites conditions testees, les 
parametres, les conditions et les actions etant modifia- 
bles par I'utilisateur du noeud d'administration. 
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D scription 


La presente invention conceme un procede de surveillance d'une pluralite de types d'objets d'une pluralite de 
noeuds a partir d'un noeud d' administration dans un systeme informatique. 

5 De maniere generale, un environnement de gestion distribuee pernnet d'integrer la gestion des systemes, des 

reseaux at des applications utilisateur Les applications de gestion sont congues de maniere a avantageusement dis- 
simuler a I'utilisateur les etapes detaillees necessaires pour effectuer des travaux de gestion et garantir Tintegrite des 
informations de gestion. Ces applications gerent des objets en utilisant des interfaces claires et concises avec les 
services communs de gestion. Les services communs de gestion permettent de simplifier le developpement des ap- 

10 plications de gestion. Des services "bases d'informations de gestion", appeles couramment par I'homme du metier 
MIB (Management Information Base), permettent aux applications de gestion de manlpuler lesdites informations de 
gestion, ces services utilisent, de preference, les normes applicaibles comme les normes OSI CMIS/CMIP (Open Sys- 
tems Interconnection Common Management Information Services/Common Management Information Protocol) et In- 
ternet SNMP (Simple Network Management Protocol). Un objet gere est, dans cet environnement informatique, une 

15 representation de ressources telles qu'une machine, un fichier, un peripherique, un utilisateur, une application, etc.. 
Une MIB qui est en fait un ensemble d'objets, represente les differentes ressources ^ administrer dans un systeme. 
Un objet d'une MIB est defini par une classe d'objets (correspondant a un type d'objet) et une instance de cette classe 
d'objets. Une requete est emise par une application en vue de consulter et/ou de modifier un objet de la MIB, elle est 
caracterisee par le type d'operation a appliquer sur un ou plusieurs des objets de la MIB. L'exploitation efficace d'un 

20 tel environnement de gestion distribuee suppose une architecture flexible qui autorise une administration aisee de 
differentes sortes d'objets. Plus formellement, dans un tel environnement, les systemes informatiques qui sont cons- 
truits sur des architectures reparties impliquent que les services requis par une application sont situes sur plusieurs 
systemes qui communiquent entre eux, comme par exemple, les systemes de transactionnels. les systemes de gestion 
de bases dedonnees SGDB, les systemes d'impression, les systemes de securite, les annuaires, etc.. Cette repartition 

25 OU distribution entratne une grande souplesse d'utilisation et autorise des gains importants en performance (reseau 
en grappe :"cluster"), cependant, le fait de multiplier les systemes a administrer pose un probleme, car cette multipli- 
cation a egalement pour effet d'augmenter de maniere significative la probabilite de dysfonctionnement sur au moins 
un systeme. Une solution a ce probleme consiste a developper des systemes d'administration pilotes par un gestion- 
naire (appele aussi "manager" par I'homme du metier) qui controle et dirige tout un systeme par I'intermediaire d'agents 

30 qui ont exclusivement pour objet d'une part, d'executer les requetes du gestionnaire utilisant principalement des fonc- 
tions du type "get" ou "set" et d'autre part d'informer ledit gestionnaire des evenements relatifs au systeme surveille 
qui utilise une fonction du type "trap". L'utilisation du protocole SNMP et d'agents SNMP fournit un exemple courant 
d'une application d'une telle organisation qui, a pour principal avantage d'etre simple, mais qui presente cependant 
de notables inconvenients dont le premier est de generer un important trafic sur la ligne entre le gestionnaire et les 

35 agents pour la transmission des requetes, des reponses a ces requetes ainsi que des evenements. Un autre important 
inconvenient est relatif a la lenteur du temps de reaction lors de I'apparition d'un evenement, ceci etant du au fait que 
Tagent concerne doit d'abord avertir le gestionnaire de cet evenement qui ensuite doit prendre une decision manuelle 
ou automatique relativement a cet evenement pour la transmettre audit agent qui a son tour ['execute et enfin en rend 
compte au gestionnaire. 

40 La presente invention a pour but de remedier a ces inconvenients de I'art anterieur et propose un procede qui, 

entre autres, permet de reduire de maniere tres significative le trafic sur la ligne et le temps de reaction lors de I'ap- 
parition d'evenements, procede qui permet de surveiller efficacement le fonctionnement d'une ou plusieurs applications 
sur une pluralite de noeuds. 

Pour cela le procede de surveillance mentionne dans le preambule est remarquabte en ce que la surveillance est 
45 configuree puis diffusee de maniere filtree a partir du noeud d'administration vers des agents autonomes, un agent 
autonome etant installe sur chaque noeud a surveiller pour, en offrant une correlation intertype, soit traiter au plus pres 
les differents types d'objets ou ensemble d'objets d'un domaine appele objet global defini de maniere generique. soit 
remonter des informations ^ visualiser vers I'interface graphique du noeud d'administration, chaque agent comportant 
une pluralite de modules specifiques propres aux differents types d'objets ou a un domaine particulier, chaque module 
50 specifique mesurant des parametres statiques et dynamiques, particuliers au type d'objet qu'il surveille et collectant 
lesdites mesures, testant des conditions sur lesdits parametres relativement a des seuils predefinis et declenchant 
eventuellement des actions associ^es auxdites conditions testees, les parametres, les conditions et les actions etant 
modifiables par I'utilisateur du noeud d'administration. 

Ainsi, selon I'idee de invention et ceci contre toute attente, l'utilisation d'agents autonomes permet de s'assurer 
55 du bon fonctionnement des applications surveillees sur I'ensemble des noeuds k I'aide d'un traitement autonome et 
efficace, de faire remonter tres rapidement des noeuds vers le noeud d'administration les informations utiles et de 
lancer de maniere automatique des actions sur certaines conditions ou de conseiller eventuellement une action. De 
cette maniere, pour assurer une surveillance efficace des applications fonctionnant sur la pluralite de noeuds, le pro- 
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cede ici applique va permettre de mesurer des parametres specifiques de chaque application, de tester des conditions 
sur ces parannetres relativement a des seuils puis d'executer une action pour prevenir d'un probleme, pour reconfigurer 
ou corriger. Pour cela, des mesures sont collectees pour realiser une analyse en temps differe dans !e but d'un examen 
statistique de Tactivite surveillee. Ces nnesures collectees concernent tous les types d'objets a surveiller, par exennple 

5 ici des instances telles que des bases de donnees comme Oracle (nnarque d'Oracle Corporation), Informix (marque 
de Informix Software, Inc.), les applications comme Tuxedo (marque de Novell, Inc.), differentes machines ou une 
quelconque machine d'un systeme, I'impression distrlbuee ("DPF" Distributed Print Facility : marque de Xerox Corpo- 
ration), etc.. Des correlations peuvent etre realisees entre plusieurs mesures differentes, en particulier, entre divers 
types d'objets : correlation intertype. 

10 L'utilisateur principal du procede est I'administrateur de I'application ou I'operateur Sauf exception, I'operateur ne 

peut agir directement autrement que pour consulter I'affichage pre-configure. De preference, pendant la surveillance, 
sont affiches I'etat des applications ainsi que les courbes de parametres choisies pour leur importance par I'adminis- 
trateur, ceci afin de permettre de verifier le bon fonctionnement de ou des objets sous surveillance. En outre, si I'ope- 
rateur ou I'administrateur desire, de maniere ponctuelle mais interactive, visualiser certaines informations plus de- 

15 taillees, un certain nombre de possibilites lui sont offertes comme I'affichage d'autres courbes de mesure ou le "zoom" 
sur des mesures ou des parties de courbes. Si, de maniere generaie, I'objet a surveiller est relatif a un objet unique 
(de base) faisant partie d'un environnement de production, ledit objet peut egalement etre un objet global (ou une 
application globale), c'est-a-dire un ensemble d'objets de base contenant, par exemple, une ou plusieurs bases de 
donnees ainsi qu'une application du type Tuxedo et eventuellement d'autres objets de base. Ces objets globaux peu- 

20 vent etre soit, prealablement connus et done traites de maniere specifique, soit non connus et, dans ce cas, traites 
comme une entite opaque mais contenant des objets de base connus. Dans chaque agent, installe au plus pres des 
objets a traiter, une pluralite de modules specifiques sont integres, chaque module etant specifique d'un type d'objet, 
Oracle, Informix, Tuxedo, systeme Unix, impression distribuee (DPF), etc.. Chaque module specifique mesure des 
parametres particuliers au type d'objet qu'il surveille, il propose, par defaut, une liste de parametres ^ mesurer, des 

25 conditions a evaluer et des actions associees. L'utilisateur a toute la latitude pour a partir du noeud d'administration, 
modifier ces choix par defaut. Chaque agent autonome installe sur chaque noeud (ou machine), outre les mesures de 
parametres qu'il effectue, les conditions qu'il evalue (sur ce noeud), les actions (reconfiguration, correction, alerte) 
associees aux conditions qu'il lance ou les traitements en temps differe qu'il opere, remonte au noeud d'administration 
les informations a afficher, telles que, par exemple, le changement d'etat des objets, les valeurs de parametres ^ 

30 visualiser sous forme de courbe, etc.. 

De cette maniere, grace a I'idee de Tinvention, le noeud d'administration a une excellente visibilite globale puisque 
le present procede permet, une fois la surveillance configuree de maniere filtree (c'est-a-dire qu'une configuration est 
propre a un objet et son environnement et qu'ainsi un meme objet peut etre configure differemment selon sa situation 
et sa distribution), de surveiller une pluralite de types d'objets, d'en donner des fonctions unifiees et egalement de 

35 permettre de correler entre elles des mesures sur des objets de type different. La correlation porte sur I'affichage de 
courbes, de conditions, d'actions associees ainsi que sur I'analyse en temps differe. II est en outre a remarquer que 
ce procede doit etre portable sur differentes plate-formes, ceci implique sa totale independance relativement a son 
environnement d'execution, la visualisation se faisant au moyen d'une interface graphique propre audit procede. Ce 
procede est prevu pour autoriser tout interfagage avec un quelconque systeme d'administration pour offrir a l'utilisateur 

40 une administration integree. Les agents autonomes accedent aux differentes informations ^ travers les protocoles 
standards existants. 

Avantageusement, pour I'application du procede de surveillance selon invention, le noeud d'administration com- 
porte entre autres, une interface graphique utilisateur pour la visualisation des objets selectionnes et I'affichage de 
courbes de valeurs de parametres, un fichier de configuration qui contient I'ensemble des configurations des objets 

45 avec la description desdits objets de meme que I'ensemble des parametres predefinis statiques ou dynamiques, ce 
fichier etant analyse et dynamiquement modifie ou complete, des fichiers d'etat des noeuds k surveiller ainsi que les 
fichiers d'affichage des parametres. les parametres mesures etant stockes dans un fichier d'analyse pour permettre 
leur affichage par I'intermediaire de interface graphique. 

De maniere remarquable, I'agent autonome installe sur chaque noeud ^ surveiller se compose principalement 

so d'un agent generique en relation avec une pluralite de modules specifiques chacun propre k un type d'objet ou ^ un 
domaine particulier, de fichiers contenant les fonctions de base utilisees, chaque noeud ^ surveiller possedant de plus 
ses propres fichiers de parametres, de conditions et d'actions associees pour controler sa propre surveillance et ainsi 
autoriser le traitement au plus pres des differents types d'objets en mesurant les parametres, en evaluant les conditions 
et en lan?ant les actions liees aux conditions et ceci pour tous les objets decrits. 

55 Egalement de maniere remarquable, lorsqu'une condition non liee k un paramfetre porte sur un ou plusieurs pa- 

rametres et done sur un ou plusieurs objets, ladite condition est traitee sur le noeud d'administration par un agent 
generique qui traite les conditions sur plusieurs noeuds, cet agent generique "d'administration" langant Taction sur le 
noeud d'administration. 


3 


BNSOOCID: <EP_0822498A1 J_> 


f 

EP 0 822 498 A1 

La description suivante en regard du dessin annexe, le tout donne a titre d'exemple non limitatif, fera bien conn- 
prendre comment I'invention peut etre realisee. 

Sur la figure unique est represente de maniere tres schematique un exemple d'application du precede conforme 
a rinvention pour Tintercommunication entre un noeud d'administration et un noeud a surveiller. 

5 Comme cela a ete vu precedemment, le precede selon I'invention permet de surveiller avantageusement n ma- 

chines, c'est-a-dire n noeuds, Ni, N2 Nn, a partir d'un noeud d'administration MN. Principalement pour i'intercommu- 
nication qui interesse I'invention, le noeud d'administration MN comporte un certain nombre de composants parmi 
lesquels I'interlace graphique utilisateur GUI et le fichier de configuration CF. L'interface GUI permet de montrer dans 
la fenetre principale sur I'ecran les objets selectionnes dans la liste des objets pouvant etre visualises, un icone pour 

10 chaque objet avec une couleur, par exemple, vert, orange et rouge, selon son etat. Egalement, lorsqu'un objet est 
selectlonne et qu'un "zoom" est demande par I'intermediaire de la barre de menus, une fenetre de nom de Tobjet est 
affichee contenant tous les objets composant ledit objet. L'interface GUI permet aussi I'affichage de courbes de valeurs 
de parametres avec, si cela est desire, plusieurs courbes dans le meme graphe. A chaque objet decrit, lors de la 
configuration de la surveillance, peut etre adjointe une liste de graphes. tandis qu'a chaque graphe est associee une 

15 liste de parametres a visualiser. L'interface GUI permet d'appeler au moins un outil d'administration pour chaque type 
d'objet alors qu'en outre, I'expertise ou I'experience memorisee d'un utilisateur ou d'un outil d'un utilisateur qui est 
d'une aide precieuse pour la surveillance, peut etre avantageusement affichee. Le fichier de configuration CF contient 
I'ensemble des configurations des objets avec la description desdits objets de meme que I'ensemble des parametres 
predefinis statiques ou dynamiques, il peut etre analyse et dynamiquement modifie ou complete. Par telechargement 

20 du fichier de configuration, par exemple, les agents autonomes sont installes, via l'interface IWMN (du noeud N1 ) avec 
le noeud d'administration MN sur les noeuds a surveiller a partir du noeud d'administration MN, une commande spe- 
cifique etant utilisee pour installer I'agent autonome SAA, comme id sur la figure, sur le noeud N1. Chaque noeud a 
surveiller possede alors ses propres fichiers SL ("scanlog") de parametres, de conditions et d'actlons associees qui 
lui permettent de controler sa propre surveillance, le noeud d'administration detenant de plus les fichiers d'etat des 

25 noeuds a sun/eiller ainsi que les fichiers d'aftichage des parametres (ensemble de fichiers "trace" TF). La mise a jour 
de la liste des noeuds ou un agent autonome est installe est faite automatiquement par le noeud d'administration. Le 
lancement et I'arret du precede de surveillance sont controles par le noeud d'administration. De maniere aisee, un 
objet nouveau peut se voir appliquer le precede selon I'invention et etre surveille par un agent autonome deja configure. 
Un agent autonome SAA est principalement constitue d'un agent generique GA en relation avec des modules speci- 

30 fiques SM (SMI, SM2,..., SMn) chacun propre a un type d'objet ou a un domaine particulier, ainsi que de fichiers parmi 
lesquels I'un est destine a contenir les fenctions de base BF utilisees. 

Le traitement des conditions peut concerner plusieurs objets, la question est alors de savoir sur quel noeud sont 
traitees les conditions. En effet, une condition peut etre liee a un parametre d'un objet, elle fait alors partie de la 
description de ce parametre. Un parametre contient la description de sa mesure (commande a lancer, analyse, affi- 

35 chage de courbe,...), la description d'un certain nombre de conditions simples portant sur la mesure qui vient d'etre 
faite (operateur, seuil, ..) avec pour chaque condition, Taction a lancer lorsque ladite condition est verifiee. Un para- 
metre est attache a un objet qui lui, est toujours associe a un noeud, le traitement du parametre et de ses conditions 
se fait done sur le noeud associe a I'objet. Par centre, une condition peut ne pas etre liee a un parametre, elle porte 
alors sur un ou plusieurs parametres et done sur un ou plusieurs objets. Dans ce cas, la condition est traitee sur le 

40 noeud d'administration ou se trouve egalement un agent generique GA' legerement different de I'agent generique GA 
contenu dans un noeud a surveiller en ce qu'il traite les conditions sur plusieurs noeuds, cet agent GA' langant Taction 
sur le noeud d'administration. En outre, une action, predefinie ou externe peut demander la valeur d'un parametre d'un 
objet surveille par un autre noeud que le noeud ou est executee Taction. Dans ce cas, une des fenctions de base BF 
qui demande la valeur va transferer cette demande au noeud d'administration qui la dirigera alors sur le noeud adequat 

45 et la valeur sera retournee en sens inverse. 

Chaque module specifique, SMI, SM2 SMn, documente sa partie predefinie en preposant des listes de choix 

par defaut de parametres a mesurer (par exemple, identifiant de parametre, description de la mesure, periode, stockage 
ou pas des valeurs dans un fichier "trace" TR affichage ou pas des valeurs), de conditions k evaluer sur ses parametres 
et d'actlons associees h lancer. Un parametre peut etre egalement une information sur I'etat d'un objet (fonctionne 
50 bien, ce qui dans I'exemple precedent correspond k un icone de couleur verte, mise en garde ou alerte correspondant 
k un icone de couleur orange, alarme ou panne correspondant a un icone de couleur rouge) ou une mesure comme 
par exemple "le nombre de transactions par secende". Si une condition de parametre est verifiee, une action est lancee 
et il est note le fait qu'une action est lancee dans un fichier de journalisation d'actiens (action, niveau, date, identifiant 
de parametre, identifiant d'objet, noeud,...)- 
55 Pendant la configuration de la surveillance, I'utilisateur du noeud d'administration decrit les objets k surveiller 

[syst^mes (Unix. .). applications (Tuxedo, ...). instances (Oracle, ...), serveur (Informix,...), ...] et sp6cifie des modifi- 
cations par rapport aux choix par defaut des modules specifiques (modification de la periode de mesure d'un parametre 
par exemple, suppression d'un parametre, ajeutd'un parametre ou d'une condition). Pour chaque nouveau parametre 
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a mesurer, il decrit la commande de mesure, precise s'il est desire afficher la mesure (sous forme de courbe), specifie 
les conditions qui vont declencher une action (une sequence de traitements). L'actlon peut consister a afficher I'etat 
"en panne" d'un objet (instance Oracle par exemple) en utilisant une fonctlon fournie par le produit ou bien effectuer 
un test de correlation avec une information systeme (taux d'occupation cpu par exemple) ou de type Tuxedo ou encore 
5 definte par rutilisateur. 

Une fois la surveillance configuree, cette derniere peut etre lancee. La configuration ne peut pas etre modifiee 
pendant une surveillance, il est pour cela tout d'abord necessaire d'arreter la surveillance pour modifier la configuration 
puis de relancer la surveillance sur tous les agents. 

Lorsque la surveillance est lancee sur chaque noeud k surveiller, le principe de base est que le "surveillant" sur 
10 chaque noeud ne dialogue pas avec le noeud d'administration sauf pour afficher I'etat d'un objet ou la courbe d'un 
parametre ou encore prevenir I'administrateur Les actions sont soit locales, c'est-a-dire internes au noeud, soit de- 
mandent un service (essentiellement d'affichage) au noeud d'administration. 

Egalement, une des fonctions de base presentee avec le present procede est prevue pour ramener (sur le noeud 
d'administration) les fichiers SL de journalisation de parametres ainsi que ceux d'actions de chaque noeud surveille, 
IS pour I'analyse independante realisee par le noeud d'administration. 

De cette maniere, I'administrateur configure la surveillance en ecrivant directement dans le fichier de configuration 
des commandes lignes. Cependant, selon une variante, il est possible d'utiliser un outil graphique de configuration qui 
generera le fichier de configuration. Ci-apr^s est propose un exemple de syntaxe des commandes ligne pour specifier 
les objets et les parametres. 

20 Un # en debut de ligne indique une ligne commentaire, ceci permet d'invalider une commande sans la supprimer 

ou de commenter le fichier. 

Suit un exemple non limitatif de specification de fichier de configuration que Tadministrateur aurait la possibilite 
de realiser pour decrire des objets qu'il voudrait surveiller, pour modifier le traitement predefini de I'agent (et des mo- 
dules specifiques) et/ou pour creer de nouveaux parametres et conditions. 
25 => MAX_CPU percent of total cpu ; 

signifie le temps maximum cpu alloue pour I'agent autonome (agent generique et modules specifiques) sur un noeud. 
Si le maximum est atteint, les modules modifient la frequence de mesure des parametres et/ou donnent priorite a 
certains traitements. 
=> PERIOD seconds ; 

30 specifie I'intervalle minimum de temps entre deux mesures d'un parametre. Cette valeur globale peut etre ponctuelle- 
ment modifiee pour un parametre ou une condition. 

35 ==> OBJECT objectjdent, 

[NODE = node] [BACKUP_NODE = backup_node] 
DESC = ( 

SYSTEM, UNIX_ADMIN_USER=<unix_user>. GIBUS_ROOT=<ism_root> 

40 

! TUXEDO. { V1CONFIG=<config_path> 

!TUXCONFIG=<tuxconfig>TUXDIR=<tuxdir>,APPDIR=<appdir>. 

45 


50 
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10 


UBBFILE=<ubbfile>. 

LANG=<lang>,UNIX_ADMIN_USER=<unix_user>, 

LIBPATH=<libpath>. QMCONFIG=<qmconfig> 

} 

! ORACLE. { V1 CONFtG=<config_path> 

!ORACLE_SID=<sid>. ORACLE_HOME=<oracle_honne>. 
UNIX_ADMIN„USER=<unix_user>. ORACLE_USER=<user>, 
ORACLE_PASSWORD=<password>, 
75 CONNECT_STRING=<connect_string>. TNS_ADMIN=<tns_admin>, 

} 

! INFORMIX, INFORMIXSERVER=<informixserver>. INFORMIXDIR=<informixdir>. 

ONCONFIG=<onconfig>, UNIX_ADMIN_USER=<unix_user> 
iSYBASE. SYBASE=<sybdir>. DSQUERY=<servername>. 

UNIX_ADMIN_USER=<unix_user>. SYBASE_USER=<user>. 
SYBASE_PASSWORD=<password> 
IXCP2POOL, CONFDIR=<confdir>. UNIX_ADMIN_USER=<unix_user> 
!GLOBAL,UNIX_ADMIN_USER=<unix_user>, 

COMPONENTS=((objectJdent. father_sev), ...) 

) 

[obj_display_clause] 

[SCANLOG=([LOGFILE=(Iogpathname,[logpathname] ...)] 
35 [ERROR_CONTROL=error_controLfile] 


20 


25 


30 


definit un objet "system" (un systeme Unix pris en charge par le module specifique "System" qui mesure le taux d'oc- 
40 cupation du cpu, le nombre d'entrees/sorties par seconde, ...). ou un objet "application Tuxedo", ou une "instance 

oracle", .., ou encore un objet "globaLobject" composed' une instance Oracle et d'une application Tuxedo par exemple. 
L'utilisateur choisit (par I'intermediaire de I'interface GUI) la liste des objets a voir (leur icone) dans la fenetre 

principale de I'interface GUI. Un objet non selectionne dans cette liste n'est vu que si un "zoom" est realise sur un objet 

global qui le contient. Un objet global peut egalement etre reference en tant que composant (COMPONENTS) d'un 
45 objet global et est composant d'un objet global [GLOBAL (une instance Oracle particuliere est choisie dans la liste des 

objets a voir dans la fenetre principale car les utilisateurs font directement du SQL sur ia base)] car cette base est 

accedee par une application donnee. Quelques termes employes ci-avant, peuvent etre ainsi explicites : 

NODE :Pour un objet SYSTEM, NODE est le nom du noeud. Pour une instance Oracle, NODE est le noeud ou 

se trouve instance. Pour une application Tuxedo. NODE est le "master node". Pour une application_globale, s'il n'y 
50 a aucun parametre cree pour cet objet, on ne mentionne pas de NODE et s'il y a des parametres crees pour cet objet, 

NODE doit etre mentionne et la mesure sera executee (la condition sera evaluee et Taction iancee) sur le noeud specifie 

par NODE. 

BACKUP_NODE : est le nom du noeud ou va tourner I'objet (le "master node" Tuxedo, I'instance Oracle, ...) en 
cas de basculement de I'application sur un autre noeud, pour raison d'exploitation ou d'arret, par exemple panne, du 
ss noeud d'origine. Cette information est utilisee pour demarrer rapidement la surveillance de I'objet sur le noeud "backup". 

ORACLE : c'est le type de I'objet qu'on decrit. ORACLE_SID est le nom de I'instance. Quand un utilisateur se 
connecte a une base Oracle, il ecrit <oracle_user>/<oracle_password>@<connect_string>. UNIX_ADMIN_USER est 
un nom d'utilisateur Unix qui sera utilise par la surveillance, depuis le noeud d'administration, pour executer des trai- 
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tements sur la base Oracle situee sur le noeud a surveiiier. 

COMPONENTS : L'identifiant d'objet (objectjdent) de tous les objets fils est donne et pour chacun des fils est 
donnee la couleur (OK [vert], WARNING [orange], DOWN[rouge]) heritee par le pere si le fils prend la couleur rouge 
(DOWN). DOWN est la valeur par defaut de "father_sev". 

5 SCANLOG : pour chaque objet I'administrateur peut designer les fichiers SL de journalisation ("log") k explorer et 

les erreurs "graves" a rechercher. Si I'option SCANLOG n'existe pas, rien n'est fait sur les fichiers "log". Si le fichier 
"log" LOGFILE n'est pas decrit (les fichiers a explorer ne sont pas specifies), chaque module specifique a predefini 
une regie de construction de la liste de fichiers a explorer. Le fichier error_control_file decrit les erreurs a rechercher 
dans les fichiers "log" et associe a chaque erreur un identifiant (chaine de caracteres) de classe d'action : si I'erreur 

10 est trouvee, I'action specifiee est appelee en lui donnant la classe d'action associee qui sert a aiguiller sur le bon 
traitement. Par exemple, "ORA-0600': 2 ACT_RESTART" veut dire que si I'erreur "ORA-0600" est trouvee dans le 
fichier alert_<sid>.log alors une action (predefinie par le module specifique ou fournie par I'administrateur en modifiant 
par MODIF_COND_PARAM le parametre predefini ORA_PARAM_LOG) est appellee en passant comme argument la 
classe ACT_RESTART ainsi que "I'objectjd", etc.. Si "ERROR_CONTROL" n'est pas decrit, le fichier predefini par 

is chaque module specifique est pris. Si une des erreurs mentionnees dans le fichier "error_controLfile" apparait, une 
action predefinie ou definie par I'utilisateur est activee. 

SC ANLOG=() veut dire prendre en compte les fichiers "log", le fichier "error_control_file" et Taction par defaut. 

^0 ==> MODIF_PARAM paramjdent 

{ [IGNORE] 

I [TRACE ! NOTRACE] [PERIOD=seconds] [NB_VALUES=:n] 
25 [param_display_clause] 

}; 

"paramjdent" est l'identifiant du parametre. Pour les parametres predefinis par les modules specifiques, "paramjdent" 
30 est un mot-cle decrit : I'utilisateur peut modifier certains attributs de ce parametre predefini [periode, analyse ("trace"), 
affichage, la condition] ou le supprimer mais il ne peut pas changer la commande. L'information a obtenir est soit un 
indicateur d'etat d'un objet (0 si "OK" [vert], 1 si "warning" [orange], 2 si "down" [rouge], par exemple) soit une mesure 
(metrique) d'un objet. 

TRACE : la mesure est stockee dans un fichier TF "trace", pour une analyse autonome. 
35 PERIOD est la periode de collecte. 

IGNORE : I'administrateur ne veut pas que ce parametre soit mesure periodiquement. Par defaut, chaque module 
specifique va mesurer regulierement un certain nombre de parametres (metrique et indicateurs de sante). Ces para- 
metres sont decrits. Chaque parametre qui est mesure est identifie de maniere unique pour un type d'objet. Exemple 
"Ora_Active_Transactions". II est permis, dans une condition ou dans une action, de demander une mesure en temps 
40 reel et non periodique d'un parametre qui a I'option IGNORE (voir la fonction de base "GetOnline\^lue"). 

NB_VALUES ; par defaut, chaque parametre predefini pourra avoir un nombre maximum de valeurs rangees dans 
une table de resultat. Ce nombre predefini est propre a chaque parametre : il depend de fonctions predefinies comme 
"get Jast_value", "get_delta", "get_average(20)". qui demandent la ou les n dernieres valeurs du parametre. Ce nombre 
predefini est done coherent avec les conditions et actions predefinies. Si I'administrateur ajoute des conditions ou 
45 actions externes qui demandent un plus grand nombre de dernieres valeurs, il modifie le nombre par "NB_VALUES" 
(la nouvelle valeur doit etre plus grande que la valeur predefinie, sinon il y a alerte ("warning") et le nombre de valeurs 
n'est pas modifie). 

50 
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==> MODIF_COND_PARAM object_ident, paramjdent, 

5 conditionrangrnumber 
{ [IGNORE] 

I [CONDITION = param_condltion] 
[ACTION=( UNIX_FILE, 'unix.file [args]' 

! UNIX_COMMAND, 'unixjmmediate_cmd' 

! SPECIF_FILE, *cx)mmand_file [args]' 

! SPECIF_COMMAND, 'specificJmmediate_command' 

] 

}: 

20 les parametres, les conditions et les actions sont predefinis completennent, I'identifiant "paramjdent" de chaque pa- 
rannetre et done la condition qui va etre traitee, ainsi que sa pertode sont decrits. 

11 est possible de modifier une condition simple predefinie associee a un parametre et identifiee par I'identifiant 
"paramjdent" du parametre et le numero de la condition (1 , 2 ou 3). S'il est desire modifie la periode, il est necessaire 
de passer par "MODIF_PARAM" de I'identifiant "paramjdent". L'administrateur peut personnaliser en modifiant toute 

25 la condition ou le seuil (et son hysteresis ou la valeur de "DURING" conformement a la condition "param_condition"), 
ou I'intervalle de valeurs d'une condition, ou supprimer ("IGNORE") le traitement de cette condition, ou encore fournir 
sa propre action a executer si la condition est verifiee. Pour "UNIX_FILE", "UNIX_COMMAND", "SPECF_FILE" et 
"SPECIF_COMMAND" voir dans la suite "CREATE_PARAM". Chaque module specifique documente ses parametres 
predefinis et en particulier sa condition : test du resultat de la mesure par rapport a un seuil ou par rapport a un seuil 

30 pendant n secondes ou par rapport a un intervalle ("RANGE"). 

==> MODIF,COND_MULTIPLE condjdent 
55 {[IGNORE] 

I [ACTION=(UNIX_FILE;unix_file [args]' 
! UNIX_COMMAND, 'unixjmmediate_cmd1) [PERIOD=seconds] 

40 } I 

permet de modifier une condition multiple predefinie identifiee et documentee sous le nom "condjdent". Les seuils 
d'une condition multiple ne peuvent pas etre modifies : l'administrateur peut supprimer la condition multiple predefinie 
45 et s'en creer une nouvelle ou il met les seuils qu'il desire. 


50 
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==> CR„PARAM object_iclent. param_iclent 

MEASURE=(SPECIF_FILE, ^command_file [argsr 
^ ! SPECIF__COMMAND. ' specific Jmmediate_command' 

! UNIX_FILE;unix_f]le [args]' 
! UNIX_COMMAND. unixjmmediate_cmd' 
,0 . [ARG_REQ] 

[STATE I METRICS] [RESULT_TYPE={1NI I FLOAT}] 

[PERIOD=seconds] 

[NB_VALUES=n] [TRACE]) [param_display_clause] 
[C0NDITION1] = (param_condition 
ACTION=(UNIX_FILE, *unix_file [args]' 

! UNIX_COMMAND. 'unixjmmediate.cmd' 
20 ! SPECIF_FILE. 'command_file [args]' 

! SPECIF^COMMAND. specific Jmmediate_command' 

) 

)] 

[C0NDITION2=(...)] 
[CONDmON3=(...)] 


35 

L'administrateur peut creer ses propres parametres et leur associer une commande ("MEASURE^"). 

SPECIF_FILE ; si I'objet est Oracle, tl est fait du SqlPlus sur le fichier sql. Autorise pour les objets de type Oracle, 
Informix, Sybase. L'execution est lancee pour le compte de Tutilisateur "ORACLE_USER" (pour Oracle) specifie dans 
I'objet. 

40 SPECIF_COMMAND : si I'objet est Oracle, il est fait du Dynannic Sql sur cette commande sql. Autorise pour les 

objets de type Oracle. L'execution est lancee pour le compte de I'utilisateur "ORACLE_USER" specifie dans I'objet. 
Longueur maximum de la commande : 512. 

UNIX_FILE et UNIX_COMMAND: la commande unix est lancee. Autorise pour tous les objets. L'execution est 
lancee pour le compte de I'utilisateur "UNIX_ADMIN_USER" specifie dans I'objet. Dans le cas de "UNIX_FILE", le 

45 fichier "unixjile" est telecharge (au demarrage de la surveillance) sur le noeud associe h I'objet reference par 
"objectjdent". Pour "UNIX_COMMAND", il n'y a pas de telechargement : la commande est transportee par le para- 
metre. 

Si "objectjdent" est un objet "GLOBAL", la commande est executee sur le noeud specifie par "OBJECT... 
NODE=node ..." 

so STATE ou METRICS : un parametre est soit un parametre d'etat (il represente le bon fonctionnement d'un objet) 

ou une metrique (le nombre de transactions par seconde, par exemple). Si "STATE", en fin de traitement de la mesure, 
il est appele la fonction d'afftchage de I'etat de I'objet (icone vert/orange/rouge) si I'etat a change depuis la derniere 
mesure. 

RESULT_TYPE : "INT" (entier) ou "FLOAT" (pour un pourcentage par exemple). 
55 CONDITION : si I'utilisateur cree un parametre et qu'il precise une condition simple, il Tecrit "dans la foulee". La 

condition est evaluee "dans la foulee" de la mesure et non independamment du moment ou la mesure est faite. 

ACTION : on specifie le nom complet d'un programme shell ou binaire suivi eventuellement de parametres 
("UNIX.FILE") ou une commande Unix ("UNIX_COMMAND") ou d'un fichier sql ("SPECIF_FILE") ou une commande 
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sql ("SPECIF_COMMAND"). Un exemple est "ACTION=(UNIX_FILE. alLactions_binary action_1')" : radministrateur 
fournit un seul programme pour toutes les actions. Ce programme aiguille selon le premier parametre qui est le nom 
d'une action particuliere. Le precede de surveillance appelera ce programme avec tous les paramelres mis dans 
"unix_file [args]" et ajoutera des parametres qui representent le contexte comme I'identifiant "object_ident", I'ldentifiant 
5 "paramjdent", la valeur du parametre (voir fonctions de base plus loin). 

ARG_REQ : mettre cette option si la mesure demande un argument qui sera fourni plus tard dans "single_condition" 
dans "GetOnline Value". Permet de faire un controle a la reference dans "single_condition". Exemple : "GetOnlineValue 
(or714.0RA_TS_FREE_PERCENT. TABLESPACE_1 )" donne le pourcentage libre de I'espace table 
"TABLESPACE_1". 

70 =^ GREATE_COND (single_condition [ AND/OR single_condition ] ...) ACTION -(UNIX_FILE , 'unixjile [args] 
[PERIOD=n] ; 

pour une condition creee par Tutilisateur, il specifie la periode et Taction. Mises entre parentheses possibles pour la 
resolution des conditions uniques ("single_condittons"). La condition est evaluee par I'agent generique G A sur le noeud 
d'administration. L'action est lancee sur le noeud d'administration (le fichier "unixjile" se trouve done sur ce noeud). 
15 obj_display_clause : 

DISPLAY^ ([GRAPH=(graphJdent TITLE="..." [TYPE=curye! pie! histogram] [MIN=min_value, 
MAX=max_value]) [GRAPH=(graphJdent... )].. ]) 


GRAPH : radministrateur associe a un objet des graphes de parametres. "TITLE" est le libelle du graphe. 
TYPE pour courbe, camembert, histogramme, quand on affiche des parametres dans un graphe de type "courbes", 


20 il faut donner la valeur min et la valeur max pour representer I'ordonnee (sachant que I'abscisse est la date de la 
mesure du parametre). Le defaut est 0,100 comme pour un pourcentage. L'icone est en vert/orange/rouge selon son 
etat ("OK", "WARNING". "DOWN"). 

=> param_display_c!ause : DISPLAY^ ("param_title", [GRAPH=(graphJdent [graphjdent]...)) 


Par defaut, aucun parametre n'est affiche, "param_title" est le libelle du parametre. GRAPH : specifier dans quels 


25 graphes se trouve le parametre. Plusieurs parametres peuvent appartenir a un meme graphe si il est desire les voir 

ensemble- 
En outre, par defaut, sur chaque type d'objet (oracle, Tuxedo, system, ...), il est fait un certain nombre decontroles 

d'etat. Si un de ces controles est negatif, il entraTne le declenchement d'une action et I'objet en question (instance 

Oracle, application Tuxedo, .. .) verra son icone changer d'etat (et done de couleur) sur I'ecran d'administration. 
30 Ci-apres, il est donne des exemples de conditions attachees a un parametre. Le caractere # veut dire "objectjdent. 

paramjdent". II n'est pas necessaire de specifier "objectjdent.paramjdent" puisque que c'est le parametre courant. 


parann_condition ::= 


35 


( 

{# 

I GetLastValue (#) 

I GetDelta (#) 

I GetAverage (#. nval) 

I GetPercentRangeChange (#, min, max, init_value) 
I GetPercentLastChange (#, init_value) 

} 

{ op6rateur valeurl [HYSTERESIS=valeur2] 

I IN (min_val, max_val) } 

) 

ou (# op6rateur valeurl DURING=nsec) 
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# ou GetLastValue (#) : la derniere valeur mesuree. C'est la fonction par defaut si on ne specifie pas de fonction : 
"objid.paramid". 

GetDelta (#): delta, en valeur absolue, entre les deux dernieres valeurs. 

GetAverage (#, nval) : moyenne des nval dernieres valeurs du parametre, pas de moyenne sur plus de 20 valeurs. 
5 GetPercentRangeChange (#, min, max, init_value) : changement par rapport a un intervalle de valeurs : (val2 - 

val1)/(max - min). 

GetPercentLastChange (#, init_value) : changement par rapport a la valeur precedente : (val2 - val1)/val1. 
operateur : <, <=, >, >=, ==, != 
valeurl : seuil 

10 HYSTERESIS=valeur2 => la condition n'est vraie que si la valeur du parametre est precedemment retombee en 

dessous de "valeur2" puis a re-atteint le seuil "valeurl Pour ne pas faire d'action en rafales. Par defaut, I'hysteresis 
a la valeur du seuil ("valeurl"). 

DURING=nsec : est-ce que la valeur du parametre est "operateur" (plus grand par exemple) que le seuil pendant 
un temps donne "nsec" ? La fonction de base transforme le temps "nsec" en nombre "nval" de valeurs puis teste que 
J5 les "nval" dernieres valeurs sont toutes "plus grandes" que le seuil. Rend 1 si vrai, 0 sinon. 
IN : est-ce que la valeur mesuree est comprise dans I'intervalle [min_val, max_val]? 

Exemple : 

20 

CREATE_PARAM OR714_NEW_PAR, or714_orage. 
MEASURE=(SPECIF_FILEyx/y/z.sql TS1 ), 
PERIOD=1h. TRACE, 


CONDITION=((# > 34), ACTION=(UNIX_FILE . myprog act1 or714')); 


En ce qui concerne la condition simple : 
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single_condition ::= 
( 

{objectjdent. paramjdent 

I GetLastValue (objectjdent, paramjdent) 

I GetDelta (objectjdent. paramjdent) 

I GetAverage (object_ident. paramjdent. nval) 

IGetPercentRangeChange (object_ident.paramJdent,min. 

max.init_value) 

I GetPercentLastChange (object_ident. paramjdent, init_value) 
I GetOnlineValue (object_ident.paramJdent. [argument]) 

} 

{ operateur valeurl [HYSTERESIS=valeur2] 

I IN (min_val. max_val) } 

) 

ou (objectjdentparamjdent operateur valeurl DURING=nsec) 

GetLastValue (objid.paramid) : la derniere valeur mesuree. Cast la fonction par defaut si on ne specifie pas de 
fonction : "objid.paramid". 

GetDelta (objid paramid): delta, en valeur absolue, entre les deux dernieres valeurs. 

GetAverage (objid.paramid, nval) : moyenne des nval dernieres valeurs du parametre, pas de moyenne sur plus 
de 20 valeurs. 

GetPercentRangeChange (objid.paramid, min, max, init_value) : changement par rapport a un intervalle de 
valeurs : (vai2 - vail )/(max - min). 

GetPercentLastChange (objid.paramid, init_value) : changement par rapport a la valeur precedente : (val2 - vail ) 
/van. 

GetOnlineValue (objid.paramid, argument) : faire la mesure en temps reel plutot que de chercher la valeur du 
parametre dans le tableau des mesures deja faites. La fonction "GetOnline" ne peut pas se trouver dans une condition 
attachee a un parametre. Elle ne peut etre que dans une condition multiple (ou dans une action). Le parametre "pa- 
ramid" a ete documente comme acceptant ou non un argument. Voir I'option "ARG_REQ" de "CREATE_PARAM". 

Une condition multiple ne pourra pas contenir plus de dix conditions simples. 

Exemple : 

CREATE_COND ((or714_orage.NB_COMMIT_PER_SEC < 23) 
AND (GetAverage(syst_orage.CPU_BUSY. 10) < 95) ) 
ACTION=(UNIX_FILE , ^myprog new_seiver or714') PERIOD=1h; 

De preference le precede selon Tinvention est utilise comme suit. L'administrateur decrit les objets a surveiller: 
"OBJECT objectjd", ... II specifie les modifications ^ apporter sur les attributs d'un parametre predefini, pour un objet 
donn6 "objectjd" : 

pour supprimer un parametre : MODIF_PARAM paramjd, objectjd, IGNORE; 

pour changer un attribut du parametre : MODIF_PARAM paramjd, objectjd, TRACE, PERIOD^... 


12 

<EP 0822498A1 I > 


♦ 


10 


20 


35 


EP 0 822 498 A1 

Ensuite il specifie les modifications a apporter sur une condition d'un parametre predefini, pour un objet donne 
"objectjd" : 

pour supprinner une condition : MODIF_COND_PARAM condjd, objectjd, IGNORE; 

pour changer tout ou partie de la condition ; MODIF_COND_PARAM condjd, objectjd, CONDITION=(# > 45); 

ou MODIF_COND_PARAM condjd. objectjd, CONDITION=( # > 95 DURING=30sec), 
ou MODIF_COND_PARAM condjd, objectjd, CONDmON=(# IN (0,350)); 


pour changer Taction associee : MODIF_COND_PARAM condjd, objectjd, ACTION=(...); 
Puis il specifie les modifications a apporter sur une condition multiple predefinie (et documentee) : 
15 . pour supprimer une condition multiple : MODIF_COND„MULTIPLE condjd, IGNORE; 
pour changer Taction associee : MODIF_COND_MULTIPLE condjd, ACTION^...; 
pour changer la periode de la condition : MODIF_COND_MULTIPLE condjd, PERIOD^: 5mn. 
Egalement, il cree un nouveau parametre a mesurer sur un objet donne : 

parametre sans condition, a analyser ("trace") : CREATE_PARAM param_id, objectjd, MEASURE=(...), PE- 
RIOD=5mn,TRACE,...; 

25 

parametre avec condition/action : GREATE_PARAM paramjd. objectjd, MEASURE=(...), PERIOD=5mn, CON- 
DITION=:((objectJd.paramJd > 95) ACTION=(UNIX_FILE , 'myprog actV). 

Enfin, il cree une nouvelle condition (multiple ou simple) sur des parametres (predefinis ou nouveaux) : 
30 CREATE_COND ( (obji.parami > 95) AND (obj2.param2 > 80 during 3mn) ) AGTION=(UNtX_FILE , 'myprog actV) 
PERIOD=15mn. 

Les actions sur condition peuvent etre explicitees comme suit. Une action est declenchee si : 


une condition sur un ou plusieurs parametres (etat ou metrique) est vraie, 
une condition multiple est vraie, 

une erreur grave apparait dans un fichier "log" ou "trace". 

40 Pour une action d'une condition attachee ^ un parametre, les parametres envoyes k Taction sont : "object Jdent", 

"paramjdent", "condition_number", "param_value". "seuir, "operateur", "object_specif_string". 
Pour une action d'une condition multiple, les parametres envoyes a Taction sont :"condJdent". 
L'action peut etre predefinie ou fournie par Tadministrateur. Elle peut comprendre : 

45 - une demande d'affichage d'etat ("ok", "down", "warning") d'un ou plusieurs "objets a surveiller" et done rafraichis- 
sement de Ticone selon Tetat k afficher. Un "objet ^ surveiller" est toujours affiche sous forme d'icone, 

une correction predefinie, immediate, avec ou sans demande d'accord via Tinterface GUI, 

50 - une proposition predefinie de correction, a lancer en differe, 

un envoi de message vers Tadministrateur [interface GUI ou historique d'un produit ou connaissance d'une gestion 
de systemes Integree, courrier, signal sonore ("beep"), ...], 

55 - une action correctrice, completement decrite par Tadministrateur Cela peut correspondre k ajouter un serveur 
Tuxedo si le taux d'occupation cpu n'est pas superieur ^ x %, 

un test de correlation sur d'autres informations "oraltuxisyst". puis si ce dernier est satisfait, action comme ci- 


13 


BNSDOCID: <EP_0822498A1_L> 


EP 0 822 498 A1 

dessus. Done demander la valeur d'un autre parametre ("last_value". moyenne sur n valeurs, "delta", valeur "on- 
line"), 

Guvrir, sur I'ecran d'administration, un dialogue avec Tadministrateur pour qu'il specifie les actions a faire. Cela 
5 permet dynamiquemeht de reagir a des problemes precis. Cecl ne devrait pas etre utilise systennatiquement dans 

les actions. 

Quelques exemples non limitatifs de realisation de parametres predefinis Oracle sont a present proposes 

10 - parametre "ORA_USER_ACCESS" dans lequel la nnesure constste a faire un essai de connexion au moyen de 
la fonction "connect_string" fournie a I'utilisateur, la condition correspond a verifier si I'essai a ou n*a pas abouti et 
Taction reside en I'analyse de la cause et en la relance eventuelle. 

parametre "ORA_FREE_TS" dans lequel la mesure consiste a determiner !e pourcentage d'espace libre par rap- 
15 port a la taille de I'espace table ("Tablespace"), la conditioni est, si la mesure est < 5%, declencher actioni qui 

correspond a creer un fichier dans un systeme de fichlers ("FileSystem") utilise par I'espace table (Tablespace), 
alors que lacondition2 est, si mesure < 10%, envoyer un message d'alerte (WARNING) vers I'interface GUI (GUI/ 
Events). 

20 . parametre "ORA_FRAGMENT_TS" dans lequel la mesure consiste ^ verifier la condition qui correspond a ce que 
la plus grande des etendues ("MAX_EXTENTS") des tables de I'espace table ("Tablespace") soit plus petite que 
!e plus grand trou de I'espace table, si cette condition est verifiee, envoyer une fenetre proposition d'action dans 
laquelle il est signifie qu'il taut reorganiser I'espace table ("Tablespace") selon les propositions suivantes : 

25 * soit, il est cree automatiquement un fichier pour agrandir I'espace table ("Tablespace"), 

* soit, il est demande quand une commande standard "d'export/traitement_tables/import" sera lancee, 

* soit, il est demande a I'administrateur de programmer le lancement de son utilitaire de reorganisation. 

parametre "ORA_SCANLOG" dans lequel les erreurs Oracle a traiter dans le fichier "alert.log" sont predefinies. 
30 A chaque erreur correspond une classe d'action predefinie. Exemple : 

ORA-0603:AGT_RESTART1 
ORA-1600:ACT_ARGHIVE_INCREASE, 

35 la mesure consistant a rechercher les erreurs predefinies dans le fichier "alert.log", la condition etant, si Terreur est 
trouvee agir en appelant Taction predefinie ou externe liee a la classe d'action de I'erreur trouvee (ACT_RESTART1 
=^ relancer instance par startup). 

Egalement, suivent des exemples non limitatifs de fonctions de base. Ces fonctions de base peuvent etre utilisees 
dans les actions fournies par I'administrateur. I'administrateur ne peut pas utiliser de fonctions demandant plus de 
40 valeurs que ce qui est possible pour un parametre (voir "NB_VALUES"). Ces fonctions de base sont egalement utilisees 
en interne dans les actions par les modules specifiques et I'agent generique. Voir les paragraphes ci-avant relatifs aux 
conditions pour certaines fonctions de base utilisees dans les conditions. 

Une fonction de base comme "GetLastValue" peut demander la valeur d'un parametre relatif a un objet surveille 
par un autre noeud. 

45 Ces fonctions doivent pouvoir etre appelees dans un programme C et dans un programme "shell". 

GetLastValue (objectjdent, paramjdent, &result_int) : retourne la derniere valeur mesuree d'un parametre. 

GetAbsDelta (objectjdent, paramjdent. &resultjnt) : retourne la valeur "difference entre les deux dernieres va- 
50 leurs" du parametre (en valeur absolue). 

GetSignDelta (objectjdent, paramjdent, &resultjnt) : retourne la valeur "difference entre les deux dernieres 
valeurs" du parametre (valeur avec son signe). 

55 - GetAverage (objectjdent, paramjdent, &result_int, nval) : retourne la moyenne sur les "nval" dernieres valeurs 
d'un parametre. Limite : "nval" ne peut pas etre plus grand que 20. 

GetOnlineValue (objectjdent, paramjdent, &result Jnt, argument) : retourne la valeur de la mesure en temps reel 
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plutot que de chercher la valeur du parametre dans le tableau des mesures deja failes. Le parametre "paramjdent" 
a ete documente comme acceptant ou non un argument (voir Toption "ARG_REQ" de "CREATE_PARAM"). Cette 
fonction ne fait que faire la mesure, ce qui signifie que si ce parametre a des conditions/actions, elles ne sont pas 
evaluees. On peut faire "GetOnlineValue" sur un parametre (et un objet) qui a I'option "IGNORE" (cela veut done 
5 dire que le module specifique a la description du parametre, sans les conditions/actions). 

GetPercentRangeChange (objectjdent, paramjdent, &result_lnt, min, max, init_value) : changement par rapport 
a un intervalle de valeurs (val2 - val1)/(max - min). Val2 est la valeur mesuree, "val1" est la mesure precedente. 

10 - GetPercentLastChange (objectjdent, paramjdent, &resultjnt. init_value): changement par rapport a la valeur 
precedente : (val2 - vall)/val1. 

SetVarString (objectjdent, variable_name, string_value) : mettre une valeur dans une variable definie. par Tutili- 
sateur. Cette variable sera utilisee dans la fonction "GetVar" pour connaltre la valeur Ce mecanisme peut etre 
?5 utilise pour transmettre des informations entre une mesure et une action, entre deux mesures, entre deux actions. 

L'etendue d'une variable est I'identifiant d'objet ("objectjdent"). Les variables sont chainees a un objet precis. 
L'utilisateur ne peut pas faire "SetVarString" sur une variable dont le nom commence par !_, ceci, afin de proteger 
les variables affectees par un module specifique. 

20 - SetVarInt (objectjdent, variable_name, int_va!ue). meme chose que pour "SetVarString" mais la valeur est un 
entier ("int"). 

GetVarString (objectjdent, variable_name, &string_ptr): retourne un pointeur (dans "string_ptr") sur la valeur de 
la variable. 


25 


GetVarInt (objectjdent, variable_name, &int_value): retourne un entier qui est la valeur de la variable. 


GetCurrentObjectId () : rend I'identifiant d'objet ("object_ident") de I'objet courant traite par le module specifique 
dans Taction. Permet, dans une action, de tester la valeur d'un autre parametre du meme objet par "GetLastVfelue 
30 (GetCurrentObjectld(),ORA_COMMITS)". 

GetLocalNodeObjectId () : rend I'identifiant d'objet ("objectjdent") de I'objet systeme du noeud local. Permet dans 
une action de tester la valeur du cpu sur le noeud local par Tintermediaire des fonctions suivantes : "GetLast Value 
(GetLocalNodeObjectld(),SYST_CPU_BUSY)". 

35 

TestDuring (objectjdent. param_ident, time, operator, threshold): retourne la valeur vrai (1) ou faux (0) de la 
condition : est-ce que la valeur du parametre est "operator", plus grand par exemple que le seuil pendant un temps 
donne. La fonction de base transforme le temps en nombre n de valeurs puis teste que les n dernieres valeurs 
sont toutes "plus grandes" que le seuil. 

40 

Trace (objectjdent, paramjdent, type_va!ue, param_value) : mettre la mesure d'un parametre dans le fichier 
"trace" pour analyse independante (nom du fichier : "appl_survey.<node>.<dateofday>.params.trc"). La fonction 
de base ajoute le nom de la machine, la date/heure. Type_value est un entier : 1 (int) ou 2 (float) 

- StopObjSurvey (objectjdent): I'agent generique envoie cette fonction vers I'interface GUI pour qu'elle affiche I'etat 
de I'objet en icone. L'agent generique met d'abord le champ "survey_status" a 1 (stop) pour Tobjet. Le champ 
"survey_status" peut etre : 0 (objet sous surveillance), 1 (objet ^ ne plus surveiller). 2 (objet dont la surveillance 
doit demarrer : par "start.survey"), 3 (objet dont on ne traite pas les parametres). 

50 - DisplayGraph (object_ident, paramjdent, param Jype. param_value) : afficher la valeur du parametre, par I'inter- 
mediaire de I'interface GUI. La fonction de base envoie egalement la date/heure. 

DisplayState (objectjdent, paramjdent, objtype, severity J evel, msg, tinelval, Iine2val) : remonter I'etat d'un ob- 
jet, pour que I'interface GUI le visualise. L'interface GUI modifie I'etat de I'Icone associe a I'objet. "Objtype" est, 
55 par exemple. ORACLE, SYSTEM, TUXEDO, etc. "Msg" est une information detaillee sur I'etat de I'objet: via le 

"bouton2" (milieu), I'interface GUI affiche cette information. L'action d'afflcher se fait sur la machine d'administra- 
tion. "Linel val" et "Iine2val" (lignes sous I'icone) sont les valeurs des deux lignes : "NULL" veut dire ne pas afficher 
la llgne sous I'icone. 
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DisplayStatelnternalSon (object Jdent, internaLobjid, paramjdent, internaLobjtype, father_sev_level, 
intemaLsevJevel, msg, linelval, Iine2vat) : remonter I'etat d'un objet, pour que Tinterface GUI le visualise. L'in- 
terface GUI modifie I'etat de I'icone assocle a I'objet. "InternaLobjtype" est, par example. "TUX_MASTER", 
"TUX_NODE", "TUX_QUEUESPACE". "Msg" est une information detaillee sur I'etat de Tobjet : via le "bouton2'' 
5 (milieu), I'interface GUI affiche cette information. L'action d'afficher se fait sur la machine d'administration. 

"Linel val" et "Iine2val" (lignes sous I'icone) sont les valeurs des deux lignes : "NULL" veut dire ne pas afficher la 
ligne sous I'icone. 

RemovelnternalSon (object_ident) : Informer I'interface GUI que I'objet pere etant "DOWN" (panne), il n'est pas 
10 possible d'acceder aux fils internes. II faut done ne plus voir les icones associes aux objets fils internes. 

SendHisto (severity, object_type, message, ack_required) : remonter un message dans I'historique d'un produit. 
"object_type" identlfie le module specifique (oracle, tuxedo, systeme, ...). 

- SendlsmAlarm (severity, object_type, message, ack_required) : remonter une alarme vers I'alarme d'un produit 
de gestion de systemes integree. "object_type" identifie le module specifique (oracle, tuxedo, systeme, ...). Seve- 
rity a preciser. 

SendMsg (severity, object_type, message, ack_required) : si "severity" est W ou I : "SendHisto". Si "severity" est 
20 A ou E et si produit de gestion de systemes integree present, en tant que "super gestionnaire", alors "SendlsmA- 

larm" sinon "SendHisto". Si "ack_required=1" : un icone drapeau (produit de gestion de systemes integree ou 
historique d'un produit) se leve indiquant qu'un message est a acquitter dans I'alarme du produit de gestion de 
systemes integree ou dans I'historique d'un produit. 

25 - DisplayMessage (message) : afficher sur la machine d'administration une fenetre contenant le message et un 
bouton "OK" pour supprimer la fenetre. 

AskForCommand (message, reponse) : afficher sur la machine d'administration une fenetre contenant le message 
demandant si I'administrateur est d'accord pour qu'on execute telle commande. Retourne la reponse (1 : oui, 0 : 
30 non) a la question. Selon la reponse, faire ou non la commande. Si aucune reponse n'est recue apres un delai 

determine, la commande n'est pas effectuee. 

"prevenir I'admin" ("mail", "beep", "msg console", ...) 

35 Suivent pour une bonne apprehension du procede divers exemples de configuration. Le premier exemple concerne 

Oracle : 


40 


45 


OBJECT or716_orage, NODE=orage. 

DESC=(ORACLE. ORACLE_SID=or716, ORACLE_HOME=/ora716, 
UNIX_ADMIN_USER=ora716, ORACLE_USER=sys. 
ORACLE_PASSWORD=change_onJnstall, 

CONNECT_STRING=P:or716, TNS_ADMIN=/ora716/network/admin) 

DISPLAY=(GRAPH=(graph_or716. TITLE=or716 graph) ); 

- modifier la p6riode d'un contrdle (mesure du param§tre d*6tat 

"ORA_CONNECT_STATUS" pr6d6fini par le module sp6cifique Oracle et 

document6) : 


55 MODIF_PARAM or716_orage, OR A_DB_ ACCESS. PERIOD^Ih; 

remplacer dans la condition la valeur du seuil d'espace libre : 

MODIF_COND_PARAM or716_orage, ORA_TS_FREE_TOOLS, 1, CONDITION = (# < 15); 


50 
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creer un nouveau parametre avec une condition/action : 


CREATE_PARAM or716_orage, USER_TS_SYSTEM_BLOCKS, 
MEASURE=(SPECIF_FlLE,/x/y/z.sql) 

[TRACE], PERIOD=12h, CONDITION=((# > 320) ACTION=(UNIX_FILE . 
/x/y/all_actions.sh acMs_system_blocks*)); 


remplacer Taction predefinie qui etait d'emettre un nnessage vers I'historique d'un produit. En fournir une autre qui 
consiste a poster dans la "crontab" I'execution d'un utilttaire Oracle sur les espaces table ("tablespaces") trop 
fragmentes : 

MODIF_COND_PARAM or71 Storage, ORA_ALL_TS_FRAGMENT, ACTION=(UNIX_FILE. 7 
oracle laction_ora action_name') ; 

supprimer le traitement d'un parametre predefini : 

MODIF_PARAM or716_orage, ORA_TS_FREE_SYSTEM, IGNORE; 

modifier les options par defaut du traitement d'un parametre predefini : 

MODIF_PARAM or716_orage. ORA_TS_FREE_SYSTEM, TRACE, DISPLAYiz(TS minfree, GRAPH= 
(graph_or716));; 

Le second exemple concerne I'ensemble Tuxedo/Oracle/System. 

decrire un objet global ( par exemple "flowbus_appli") constitue par une application "Tuxedo tux_demo_fb" (dont 
le "master node" est orage) qui utilise une base "Oracle or714_orage" et tournant sur le noeud "syst^orage". A 
chaque objet est associe un graphe de courbes de mesures. Les objets (leur icone) "tux_demo_fb" et 
"or714_orage" ne sont visualises que si I'utilisateur demande un zoom apres avoir cliquer sur I'objet global 
("flowbus_appli") : 


OBJECT syst_orage, NODE=orage, 
DESC=(SYSTEM) 

DISPLAY=(GRAPH=graph_orage, TITLE=orage perfs ); 
OBJECT tux_demo_fb. NODE=orage 
DESC=(TUXEDO. 

TUXCONFIG=/flowbus/val/test/marcel_demo/bin/TUXCONFIG, 
TUXDIR=//usr/tuxedo, 
APPDIR=/flowbus/val/test/marcel_demo/bin, 

UBBFILE=/flowbus/val/test/marceLdemo/bin/UBBCONFIG, 
LANG=C, UNIX_ADMIN_USER=fb_user, 
QMCONFIG=/flowbus/val/test/marcel_denno/bin/QUE, 
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LIBPATH=/flowbus/val/test/marcel_demo/bin:/usr/tuxeclo/lib:/ 
flowbus/install/lib:/:/lib:/usr/lib:/usr/lib/cx)bol/coblib), 
DISPLAY=(GRAPH=(graph_tux_demo_fb. TITLE=tuxedo demo_fb 

stats); 

OBJECT or714_orage, NODE=orage 

DESC=(ORACLE. ORACLE_SID=or714, 
ORACLE_HOME=/ora714. UNIX_ADMIN_USER=ora714. 
ORACLE_USER=sys, 
ORACLE_PASSWORD=change_on_install, 

CONNECT_STRING=ior714, 
TNS_ADMIN=/ora714/network/admin) 

DlSPLAY=(GRAPH=graph_or714, TITLE=or714 perfs ); 
OBJECT flowbus_appll. 

DESC=(GLOBAL_OBJECT. COMPONENTS=((syst_orage, 
DOWN),(tux_demo_fb, DOWN), (or714_orage. WARNING)). 
DISPLAY=(GRAPH=graph_flowbus_a, TITLE=global flowbus_a 
perfs ); 

creer un nouveau param^tre nombre de messages dans la queue Q1 , sans condition/action : 

CREATE^PARAM tux_demo_fb, Q1_MSG_NB, MEASURE=(UNIX_FILE 
/x/y getJgQI) 

[TRACE], PERIOD=60s, DISPLAY=(nombre de messages dans 
Q1 . GRAPH=(graph_tux_demo_fb); 

afficher des parametres dans des graphes de mesures : 

MODIF_PARAM syst_orage, SYST_CPU_BUSY. DISPLAY=(cpu busy, GRAPH=(graph_flowbus_a, 
graph_orage)); 

MODIF_PARAM syst_orage, SYST_IO_HDISKO, DISPLAY=(hdiskO : KB/sec, GRAPH=(graph_flowbus_a, 
graph_orage)); 

MODlF_PARAM or714_orage, ORA_SRV_NB, DISPLAY=(nombre de serveurs oracle dedies, GRAPH= 
(graph_flowbus_a, graph_or714)); 

MODIF.PARAM or714_orage, ORA_COMMlT_PER_SEG, DISPLAY=(nombre de commits/sec, GRAPH^ 
(graph_or714)); 

MODIF_PARAM tux_demoJb, TUX_TPS. DISPLAY=:(nonnbre de services/sec, GRAPH=(graph_flowbus_a, 
graph_tux_demo_fb)); 
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MODIF_PARAM tux_demo_fb, TUX_CL1ENT_NB, DISPLAY=(nombre de clients Tuxedo, GRAPH= 
(graph_flowbus_a, graph_tux_demo_fb)}; 

MODlF_PARAM tux_denno_fb. TUX_SERVER_NB, DISPLAY=(nombre de serveurs Tuxedo, GRAPH= 
(graph_flowbus_a, graph_tux_demo_fb)); 

Les graphes suivants seront affiches si il est clique sur le "boutonS" des objets : 

Graphe "graph_flowbus_a" : "click" sur "objet flowbus_appli" 


cpu busy 
hdiskO : KB/sec 

nombre de serveurs oracle dedies 
nombre de services/sec 
15 nombre de clients Tuxedo 

nombre de serveurs Tuxedo 

Graphe "graph_orage" : click sur "objet syst_orage" 

20 cpu busy 

hdiskO : KB/sec 

Graphe "graph_tux_denno_fb" : "click" sur "objet tux_demo_fb" 

25 nombre de messages dans Q1 

nombre de services/sec 
nombre de clients Tuxedo 
nombre de serveurs Tuxedo 

30 Graphe graph_or714 : "click" sur "objet or714_orage" 

nombre de serveurs oracle dedies 
nombre de commits/sec 

35 Le troisieme exemple est relatif a FSX. 

OBJECT fs_oracle_orage NODE=orage DESC=(FILESYSTEM, NAME=7oracle", MIN_FREE=20, MAXSI- 
ZE=300MB, INCRSIZE=1MB); 

modifier la periode du controle (mesure du parametre "FS_FREE_SPACE") 
40 MODIF_PARAM fs_oracle_orage. FS_FREE_SPACE. PERIOD=1h; 

remplacer Taction predefinie qui est d'agrandir le systeme de fichiers, jusqu'a la taille maximale. En fournir una 
autre qui consiste a tester que tel fichier "log" ne grandit pas anormalement, auquel cas. voir si le niveau de "trace" 
est correct et si ce n'est pas le niveau de "trace" qui n'est pas adapte, alors ... : 
45 MODIF_COND_PARAM fs_oracle_orage. FS_FREE_SPACE, ACTION=(UNIX_FILE, Voracle/actionjs 

action_name') ; 

remplacer la valeur du seuil "minfree" : 

MODlF_COND_PARAM fs_oracle_orage, FS_FREE_SPACE. CONDITIONr:(# < 15 HYSTERESIS=18) ; 

50 

En fonctionnement autonome ("offline"), la collecte des parametres se fait dans un fichier "paramlog" sur chaque 
noeud surveilte. Les actions sont enregistrees dans un fichier "actionlog" sur chaque noeud surveille, en particulier 
pour ; 

55 - permettre la gestion d'archives sur une periode plus ou moins longue, I'affichage d'activites passees, les rapports 
de statistiques (sur un jour/semaine/mois/an et differents zooms sur les informations "systeme/DB/TP/EpochBac- 
kup/). Permettre les statistiques par application Tuxedo, par instance de base de donnees, par application X ou 
Y, par "machine/cluster". Permettre la collecte/analyse d'informations pour surveiller que la mise au point ("tuning" 
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25 


SGA, ...) est toujours correcte (via un appel a "DbaExpert" ou autre). Stocker les recommandations. 

L'agent autonome conforme a I'idee de invention se compose principalement d'un agent generique et d'une plu- 
ralite de modules specifiques a chaque type d'objet : oracle, tuxedo, systeme, DPF, FSX, SAP ... Le travail global 
5 consiste a mesurer des parametres, si besoin est les stocker dans un fichier "trace" et permettre leur affichage par 
rintermediaire de I'interface GUI, a evaluer les conditions simples ou multiples et a lancer Taction liee a la condition 
vraie et ceci pour tous les objets decrits dans le fichier de configuratiion. 

L'agent generique "d'administratlon" (sur le noeud d'administration) gere les donnees d'entree suivantes : 

10 - d'un cote toutes les donnees qui ont ete predefinies par chaque module speciflque, pour tous les objets du meme 
type : 

* des parametres avec leurs attributs (periode de mesure, analyse (trace )/affichage avec sa periode). Chaque 
parametre a un identifiant de parametre. L'administrateur peut modifier des attributs de ce parametre. 

15 

* eventuellement, une condition simple associee a un parametre ou une condition multiple sur plusieurs para- 
metres, ainsi que Taction liee a la condition. Une condition simple ou multiple est identifiee (identifiant du 
parametre pour une condition liee a un parametre ou identifiant de condition pour une condition multiple) : 
l'administrateur peut modifier des attributs de cette condition. 

d'un autre cote toutes les donnees qui ont ete specifiees par l'administrateur : 

des modifications sur les attributs predefinis : analyse ("trace"), periode, affichage, les donnees pour un objet 
particulier ou la suppression d'un parametre. 

* des modifications sur les conditions predefinies : changer le seuil d'une condition simple, Taction, la periode 
ou supprimer la condition. 

* des creations de parametres avec eventuellement une condition simple. 

* des creations de conditions simples ou multiples avec une action associee. 

Le traitement de Tagent generique d'administration se fait de la maniere suivante: 

35 - lecture de son fichier de configuration. Analyse syntaxique et semantique ("MODIF_PARAM" d'un parametre 
inexistant, ...). 

fusion du fichier de configuration fourni par l'administrateur et du fichier de configuration fourni par les modules 
specifiques. 

40 

envoi du fichier de configuration resultant a chaque agent (en filtrant relativement aux objets a surveiller sur la 
machine et en tenant compte des problemes inherents aux noeuds en panne ou aux noeuds prevus pour la sau- 
vegarde des donnees d'un noeud en panne sur un autre noeud). 

45 Le traitement de Tagent generique d'un noeud autre que le noeud d'administration se fait de la maniere suivante : 

lecture de son fichier de configuration, seuls les objets locaux ^ ce noeud sont traites. 

- construction de la table d'objets ("OBJECTS"). 

50 

construction de la table de configuration des parametres ("CONFIG_PARAM"). 

construction de la table des valeurs de parametres ("PARAM_VALUES"): 

55 * chaque parametre de chaque objet a au molns un emplacement pour mettre sa/ses valeur(s). S'il y a des 

fonctions comme moyenne ("paramid", 20) ou duree d'execution, alors le nombre d'emplacements a r^server 
pour ce parametre de cet objet est calculi. 
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construction de la table des conditions multiples ("COND.MULTIPLE"). 

fourniture des fonctions de base a I'usage des modules specifiques pour certaines et pour les actions externes 
pour d'autres. 

5 

lancement des modules specifiques : 

* les modules specifiques "lourds" comme Oracle, Informix, Tuxedo possedent un traitement propre. D'autres 
comme FSX. DPF peuvent etre regroupes dans un seul traitement. Le but est de ne pas serialiser toutes les 

10 surveillances mais d'en faire un certain nombre en parallele. L'ensemble global ne doit quand meme pas 

consommer plus que le taux maximal ("MAX_CPU") de cpu autorise. 

* ne lancer que les modules qui ont un objet a surveiller. 

IS - configuration a partir du service de surveillance de fichiers, par exemple RSF ("Remote System Facility"), de 
maniere a permettre le traitement de I'exploration des fichiers de journalisation ("logs") de tous les objets decrits. 

evaluation de chaque condition multiple, avec sa periode : 

20 * chercher les valeurs des parametres dans la table des valeurs de parametres ("PARAM_VALUES") ou via la 

fonction "get_online". 

* si la condition multiple est verifiee : lancer Taction (interne ou externe). 

25 - surveillance reguliere du bon fonctionnement des modules specifiques (envoi d'un parametre special et attente 
de la reponse). 

Outre les fonctions de base fournies k Texterieur, Tagent generique et les modules specifiques utilisent les fonctions 
de base internes suivantes : 

30 

PutValue (objectjdent, paramjdent, param_value) : ranger dans la table "PARAM_VALUES" la derniere valeur 
d'un parametre donne d'un objet donne. Cette fonction est utilisee par les modules specifiques apres la mesure 
du parametre. 

35 - ExecMeasure (param_entry) : voir "traitement d'un parametre". 

ProcessHysteresis (objectjdent, paramjdent, param^value) : si le champ "action" n'est pas valide 
("ACT!ON_SWITCH OFF") aiors tester "param_value" avec I'hysteresis. Si inferieur (en fait operateur inverse de 
celui pour le seuil) valider ce champ ("ACTION_SWITCH ON") sinon I'invalider ("ACTION_SWlTCH OFF"). 
40 "ACTION_SWITCH" est un champ de la structure condition et est initialise a "ON". Si on place "ACTION_SWITCH" 

a "ON" pour une condition, il faut faire de meme pour les conditions de rang superieur, c'est-^-dire les conditions 
2 et 3 si on met "ACTION_SWITCH" a "ON" pour la condition 1 . 

EvalConds (param_entry) boucle sur les conditions d'un parametre et appelle "EvalCond" (voir "traitement d'un 
45 parametre"). Cette fonction permet de tester le champ "action_switch" de I'entree parametre avant de lancer Tac- 

tion. 

EvalCond (cond_entry) evalue (vrai/faux) une condition. 

50 - ActionCondParam (object_ident, param_ident, condition_number, param_va!ue, condition_buffer, 
object_specif_string) et ActionCondMultiple (action_name, actionjype, cond_ident) : Ces fonctions permettent 
de lancer une action. . Si "actionjype" est interne ("internal", predefini par le module specifique) alors appeler un 
point d'entree interne au module specifique en lui passant les arguments "object_ident", etc.. Si "actionjype" est 
externe (''externaT', fourni par I'administrateur) et si un fichier specifique est concerne ("SPECIF_FILE"), appeler 

55 un point d'entree du module specifique qui traite le fichier de commande, mais si c'est une commande specifique 

qui est concernee ("SPECIF_COMMAND"), appeler un autre point d'entree du module specifique qui traite la 
commande. Dans le cas ou un fichier Unix ou une commande Unix ("UNIX_FILE" ou "UNIX_COMMAND") sont 
concern^s, ouvrir le fichier de synchronisation appele aussi "tube" par Thomme du metier (commande "popen" qui 
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est la contraction de "pipe open") sur la chaine fournie en ajoutant comma arguments ce qui permet de caracteriser 
le contexte : "objectjd", "paramjd". ... La fonction de base enregistre dans le fichier "actionlog" du noeud local 
le fait que cette action est executee : nom du fichier "actionlog appl_survey.<node>.<dateofday>.actions.trc". 

5 Ces fonctions de base sont utilisees par les modules specifiques et doivent pouvoir etre appelees dans un pro- 

gramme C. 

Le traitement d'un module specifique (systeme Unix, courrier, FSX, impression DPF [Distributed Print Facility], 
oracle [base de donnees], informix [systeme de bases de donnees Unix], Tuxedo [application], FlowBus [gestionnaire 
de flux interapplication], XCP2 [extended Cooperative Protocol level 2], SAP [Service Access Point], ...) se fait de la 
70 maniere suivante : 

exploration de la table de configuration des parametres ("CONFIG_PARAM"), en ne traltant que ses propres 
objets : 

75 * parametres deja tries par periode croissante. 

* pour chaque parametre de chaque objet, selon la periode : 

faire la mesure en utilisant la commande interne (parametre predefini) ou externe ("CREATE_PARAM"), 
20 la mettre dans la table "PARAM_VALUES". 

si une analyse ("trace") est effectuee, mettre la valeur dans le fichier "trace" global de Yagenl autonome 
(voir fonctions de base). 

25 . si un affichage est demande, afficher la valeur ou I'etat. 

evaluer la condition simple, si elle existe, lancer faction (Interne ou externe) si la condition est vraie. 

traitement des demandes inopinees ("get_onllne") de mesure en temps reel de parametre. 

30 

Le traitement d'un parametre est effectue de la sorte : 

si le parametre est valide et la periode determlnee : 
si param.valid_param_entry & param.period_OK 
35 alors return_code = ExecMeasure (param„entry) 

si une condition sur un parametre existe et que le parametre est valide 

si param.cond_exists & param.valid_param_entry & (return_code =~ 0) 
alors EvalConds (param_entry) 

40 

Le contenu de la fonction de base "Execf^easure" pour realiser la mesure de parametre est plus precisement 
explicite ci-dessous : 

si param.measure_type="internal", alors 
status=param.measure_cmd(param.param_!dent,object_ident,&param_value) 
45 sinon status=executer param.measure_cmd (programme shell ou binaire) avec pour argument : (paramjdent, 

I'objectjdent), lancer en redirigeant sa sortie dans un "pipe". Convention : le programme externe met sa valeur dans 
sa sortie standard et la valeur du parametre mesure est recuperee en lisant le fichier "pipe", 
si (status == 0), alors 

PutValue (param.objectjdent, param.paramjdent, param_value) si param. trace alors Trace(param. 
50 objectjdent, param.paramjdent, param_value) 

si param. param_disp!ay alors DisplayGraph (param.objectjdent, param.paramjdent, param_value) 
Le contenu de la fonction de base "EvalConds" pour evaluer les conditions sur les parametres est plus precisement 
explicite ci-dessous : 
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pour i=1 ^ nbconds 

ProcessHysteresis (param.objectjdent, param.param_ident, 

param_value) 

si ACTION_SWITCH OFF ==> next cx)ndition 
bool = EvalCond (param.cond_entry(i)) 


si (bool == true) & (action_switch == ON) alors 
^5 {ActionCondParam (param.objectjdent, param.paramjdent, 

paramlcondition number, param_value. param.cond_entry(i), 
object_specif_string) 
ACTION_SWITCH = OFF 
break 

} 


Suivent deux exemples de code, le premier relatif au code de la commande de mesure ("measure_cnnd") du 
module specifique, plus particulierement du module specifique "FILESYSTEM" (FS): 


dispatch (paramjdent) 


FS_FREE_SPACE : 
^5 appel_mesure param.name free_percent, currsize 

si mesure KO ("name" non trouv6 ou pas mont6) alors 
SendHisto (AS, "Filesystem %param.name not found in 
%param.node machine") 
param.measure_rc=DOWN 
retum -1 

sinon *param_value = free_percent 
return 


Le second exemple est relatif au code "d'action du module specifique" : 


55 


BNSOOCID: <EP_0822498A1J_> 


23 


EP 0 822 498 A1 


dispatch (action_name) 

FS_FREE_SPACE_ACT1 : 

si (cunrsize < obj.maxsize) alors 

si ((currsize + obj.incrsize ) > obj.maxsize) alors incr_t=obj.maxsize - 

currsize 
sinon incr_t=obj.incrsize 
appel chfs_command (name. incr_t) 
return. 

A ce stade de la description, plusieurs remarques sont a faire : 

la mesure envoie les messages si un probleme est rencontre dans ladite mesure. 

si n conditions sont innposees, une seute action est effectuee, celle de la premiere condition vraie ("cond1 " puis 
"cond2" puis "cond3"). 

les champs suivants sont a prevoir dans I'entree "param" : 

measure_rc (OK,KO) 
param_state (state, metric) 

action_switch (ON, OFF) : initialise a ON, mis k OFF si la valeur du parametre est inferieure (en fait operateur 
inverse de celui pour le seuil) a I'hysteresis. Par defaut, {'hysteresis a la valeur du seuil. 
Le champ "action_sw" est teste dans la fonction de base "EvalConds". 

un parametre "state" a toujours ses deux dernieres valeurs dans la table "resultat". 

a un instant donne, I'acces est autorise a une entree objet et a une entree parametre. 

lorsqu'un agent est deporte sur le noeud d'administration pour surveiller une pluralite de noeuds, il peut etre ne- 
cessaire de prevoir un gestionnaire (manager) SNMP qui dialogue avec les agents SNMP standard sur les noeuds 
concernes. Get agent deporte gere les fichiers "paramlog" et "actionlog" sur le noeud d'administration. 

Le traitement des actions est realise comme suit : 

ragent generique et les modules specifiques demandent a lancer une action (predefinie ou fournie par I'exterieur). 

toute action regoit des arguments qui representent le contexte qui declenche Taction : 

I'identifiant d'objet (object Jdent), I'identifiant du parametre (paramjdent), le numero de la condition 
(condition_number, si condition multiple). 

pour une condition simple : la valeur mesuree du parametre, son seuil et son hysteresis, I'operateur (>,<,=, !=). 

Le lancement d'une action est traite par une fonction de base : voir ci-avant avec les fonctions de base " Action- 
CondParam" et "ActionCondMulttple". 

En ce qui concerne le traitement des fichiers de journalisation ("logs") des applicatifs, pour chaque module spe- 
cifique, toute erreur specifiee dans le fichier "ERROR_CONTROL" qui apparalt dans un fichier "log" de I'objet ("alert, 
log", "ULOG", ...) gen^re {'execution d'une action. Pour chaque objet a surveiller, I'administrateur specifie la liste des 
fichiers "logs" k explorer ("SCANLOG" dans la commande "GR_OBJECT" de la configuration) et un fichier de contrdle 
d'erreur ("error control file"). Des valeurs par defaut sont prevues. Ce fichier de controle d'erreur decrit les erreurs k 
s6lectionner (les "ora_err" par exemple) et la classe d'erreur associee k chaque erreur Cette classe d'erreur sera 
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transmise a Taction liee a la condition du parametre predefini "PARAM_LOG" et servira a un aiguillage plus fin sur la 
sequence de traitennents a fairs qui consiste, par exemple, a sauver des fichiers d'analyse ("trace") ou des informations 
complementaires. La sequence de traitennents dans I'action est predefinie nnais peut etre entierement ecrite par I'ad- 
ministrateur. II est innportant de rappeier que toute action declenchee entraine I'enregistrennent ("logging") dans le 
5 fichier "actionlog" avec le nnessage d'erreur dans ce cas. Un exemple de fichier de controle d'erreur ("error_control_file") 
est ci-apres propose : 

"ORA-0603":ACT_RESTART1 

"ORA-1600":ACTJNCREASE_ARCHIVE 

10 Avant de lancer les modules specifiques, I'agent generique genere une configuration "RSF" pour chaque objet si 

le fichier "SCANLOG" est decrit pour I'objet. 

si le fichier "LOGFILE" decrit les noms des chemins des fichiers de journalisation ("logpathname") : une entree 
dans la configuration "RSF" par le nom du chemin de fichier de journalisation ("logpathname"). 

75 

si le fichier "LOGFILE" n'est pas decrit, I'agent generique appelle une fonction du module specifique ("mstype" est 
le type du module specifique) "<mstype>_build_!ognames (object_entry, lognames_array)" qui retourne une liste 
de noms de fichiers a explorer, comme par exemple avec Oracle : 
$dbhome/rdbms/log/alert_<sid>.log, 
20 $dbhome/network/log/listener.log,$dbhome/ 

sqlnet.log, etc... L'agent generique appelera, par exemple, I'application Tuxedo chaque jour juste apres minuit car 
le nom du fichier "log" contient la date du jour. 

La configuration "RSF" est personnalisee par le fichier "error_controLfile". Si une erreur est trouvee dans un nom 
25 de chemin de fichier de journalisation ("logpathname"), un message est genere vers le fichier "ApplicationJournal" et 
un message est genere dans le fichier "error_param_<mstype>" sur le noeud a surveiller et dans le fichier "AS_scanlog" 
dans le repertoire "GUI_FILES_DIR" sur le noeud d'administration. de format : 
objectjd error_code act_class logpathname ligne_contenantJ_erreur. 
Puis I'agent generique lance le traitement de la configuration "RSF". 
30 Le module specifique a predefini un parametre "PARAM_LOG" (qui est ignore si I'optlon "SCANLOG" n'existe pas 

pour I'objet). Dans ce cas, il effectue une mesure qui consiste a lire un message dans le fichier "error_param_<mstype>" 
sur le noeud a surveiller, pour I'identifiant d'objet ("objectjd") courant. Le module specifique gere un point courant par 
I'identifiant d'objet ("objectjd"). Si la condition posee "message trouve" est verifiee, I'action associee est appelee, avec 
comme arguments le contexte classique. le code erreur ("error_code"), la classe d'action ("act_class"), le nom de 
35 chemin de fichier de journalisation ("logpathname") et la "ligne_contenant J_erreur". L'action predefinie va permettre 
d'enregistrer le fait que la ligne a ete trouvee. Cette action predefinie peut etre remplacee par I'administrateur par une 
action externe. 

En ce qui concerne I'analyse autonome ("offline"), la collecte des parametres se fait dans un fichier parametre sur 
chaque noeud surveille. Les conditions vraies sont enregistrees dans un fichier d'analyse ("trace") sur chaque noeud 

40 surveille. Une telle analyse autonome est utilisee pour la gestion d'archives sur une periode determinee, pour I'affichage 
d'activites passees, pour les rapports de statistiques (sur un jour/semaine/mois/an et differents zooms sur les infor- 
mations relatives au "systeme/DB/TP/Epoch Backup/). Des statistiques peuvent etre ainsi etablies par application Tuxe- 
do ou pour une quelconque application, par instance de base de donnees, par "machine/cluster", etc.. La collecte et 
I'analyse d'informations pour surveiller que la mise au point ("tuning", SGA, ...) est toujours correcte. L'analyse auto- 

45 nome peut etre egalement realisee en ramenant les fichiers "paramlog" et "actionlog" de chaque noeud "N_agent" sur 
le noeud "N_admin". L'analyse autonome peut etre de plus realisee en recuperant les fichiers d'analyse ("trace") des 
outils comme "DbaXpert" (Db*Activity, space monitor) ou autres. 

L'arret du surveillant sur le noeud "N_admin" arrete les surveillants sur les noeuds "N_agent". 

II peut etre ici rappele que la configuration de la surveillance est diffusee de maniere filtree a partir du noeud 

50 d'administration vers chaque agent autonome de chaque noeud ^ surveiller au moment du lancement dudit agent 
autonome, sachant que chaque noeud a surveiller a ses propres fichiers de journalisation de parametres ("paramlog") 
et d'action ("actionlog") ainsi que ses propres processus de surveillance, tandis que le noeud d'administration, en tant 
que tel, possede de plus les fichiers d'etat des objets surveilles ("obj_state") et d'affichage des parametres 
("display_params"). Chaque agent est " react ivable" automatiquement, ceci signifie que lorsqu'un agent devient actif 

55 sur un noeud, il commence par lancer la commands "mkitab" pour se mettre dans la table d'initialisation ""inittab" pour 
pouvoir etre reactive si le processus meurt ou si le noeud tombe en panne puis est reactive. Quand un agent est 
desactive, il lance la commands "rmitab" pour ne pas etre reactiver alors que le noeud d'administration ne le connaTt 
plus. 
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Si un noeud a surveiller est declare indisponible ou hors d'usage, ses objets (instance oracle, application 
Tuxedo, ...) qui etaient a surveiller et qui ont ete bascules sur un noeud de secours ("backup") doivent etre suivis par 
I'agent autonome sur le noeud de secours. Une maniere simple peut etre de modifier le fichier de configuration sur le 
noeud de secours en remplagant le nom du noeud indisponible par le nom du noeud de secours, ceci signifiant que 
5 toute la configuration est envoyee aux agents sans supprimer les objets non surveilles par un agent sur un noeud 
donne. Pour cela, la commande : 

NewObject old_node_objectJdent OBJECTS=(objectJdent, objectjdent ...), 

qui permet de faire connaitre k I'agent sur le noeud de secours les nouveaux objets a surveiller, objets qui etaient 
surveilles par I'agent sur le noeud devenu indisponible. Dans "OBJECTS" ne sont specifies que les objets (base Oracle, 
10 application Tuxedo, ...) qui ont ete bascules sur le noeud de secours. 

De maniere non limitative, les principals caracteristiques de quelques modules specifiques sont ci-apres preci- 
sees. Ainsi, relativement au module specifique a FSX, il doit etre, entre autres, permis : 

de specifier, pour le procede selon I'invention, des objets a surveiller relatifs aux systemes de fichiers ("FILESYS- 
15 TEM") et relatifs a la pagination ("PAGING„SPACE"). 

d'appeler et integrer interface GUI de configuration FSX depuis le menu "Configuration" du present procede. 

d'autoriser des traitements tels que le controle periodique sur I'espace libre du disque et son extension. 

20 

de modifier la periode du controle ou changer d'action si le controle est positif. 

de mesurer des parametres tels que le coefficient d'occupation et la taille maximale ("free_percent" et "max_size") 
en utilisant la condition predefinie (si free_percent < config_min) et (max_size + incrsize <= config_max) alors 
2S action d'extension. 

a I'administrateur de creer des conditions contenant [si (condition) et si (objl.free_percent < n)] alors ... 

De meme, relativement au module specifique a I'impression distribuee (DPF), il doit etre, entre autres, permis : 

30 

de mesurer des parametres de performances (nombre de pages par heure, par exemple). 
de demander une impression, de gerer les demandes d'impression, de gerer les queues, les dispositifs. 
35 - de demarrer et arreter le traitement differe sur un noeud. 
de configurer les fichiers de traitement differe. 

de controler I'etat des fichiers de traitement differe, des queues locales, des dispositifs et des demandes d'impres- 
40 sion avec, si un probleme est rencontre, la possibilite de mise d'un message dans un fichier "log" explore par 

"RSF" qui alarme I'administrateur. Ces controles sont fatts par un "demon" "dpf_status_chk" sur chaque noeud du 
domaine DPF. 

de controler I'etat des serveurs DPF et generer automatiquement Taction qui corrige I'etat anormal. Un outil comme 
45 "lb_admin" trouve les sen/eurs enregistres et le "demon" "dpf_server_chk" controle que ces serveurs repondent. 

S'ils ne repondent pas, ils sont automatiquement "tues" et I'enregistrement supprime alors qu'un message est mis 
dans le fichier "log" explore par "RSF" qui lance une alarme : alarme (fenetre "affichage d'un message" ou dialogue 
pour savoir si I'administrateur veut qu'une action proposee soit executee (avec resultat visualise dans une fenetre), 
I'etat (et des informations detaillees) etant remonte vers I'interface GUI pour visualisation alors que de plus il est 
50 possible de changer la periode de certains tests (done documentes et identifies "paramjdent" par le module 

specifique), de supprimer un parametre "controle", et de dire si une analyse ("trace") est desiree ou non. Les 
"demons" sont lances automatiquement par le systeme d'exploitation ("process init") et redemarres automatique- 
ment lors de I'apparition d'une panne. Le nom du chemin "pathname" du fichier "log" explore par "RSF" est con- 
figurable. 

55 

d'appeler un outil d'administratton dans le menu "Tools" comme DbaXpert, Tux_GUI, Onperf, ... 
de collector des metriques. 
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Suit un exemple de mise en oeuvre du module specifique a DPF : 

parametre DPF_SPOOLER_STATUS 
mesure : 

npstat -h <uname_node> 1> resultfile 2>npstat_errorrile 
si ($? != 0) 

SendMsg (E. npstat failed. npstat_errorfile) 
rc= $? 

sinon 

traitement resultfile => System <spooler> <status> 
return current_param_value=status in (started, stopped, inconsistent. -) 
condition 1 : 

si (GetDelta(current_obj. DPF_SPOOLER_STATUS. &val) != 0) 
action 1 : 

si (current_parann_value != "started") 

DisplayState (cun^ent.obj. DPF_SPOOLER_STATUS. DPF_SPOOLER. 
severe_color, current_param_value) 

SendMsg (A, <spooler> is <cunrent_param_value>) 

sinon 

DisplayState (cun'ent_obj. DPF_SPOOLER_STATUS. DPF_SPOOLER. 
ok_color. current_param_value) 

SendMsg (W. <spooler> is <curent_param_value>) 

parametre DPF_QUEUE_INSTATUS 
mesure : 

npstat -h <uname_node> 1> resultfile 2>npstat_errorfile 
si ($? != 0) 

SendMsg (E. npstat failed. npstat_errorfile) 
rc= $? 

sinon 

traitement resultfile => Queue <queue_name> <instatus> <outstatus> 
<requests> 


50 
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return current_param_value=instatus in (accepting, rejecting) 
condition 1 : 

si (GetDelta(current_obj, DPF_QUEUE__INSTATUS, &val) != 0) 
action 1 : 

si (current_param_value != "accepting") 

DisplayState (current^obj, DPF_QUEUEJNSTATUS, DPF_QUEUE, 
warning^coior, current_param_value) 

SendMsg (W, <queue_name> is <current_param_value>) 

sinon 

DisplayState (current_obj, DPF_QUEUE_INSTATUS. DPF_QUEUE, 
ok_color, current_param_value) 

SendMsg (W. <queue_name> is <current_param_value>) 

parametre DPF_QUEUE_OUTSTATUS 
mesure : 

npstat -h <uname_node> 1> resultfile 2>npstat_errorfile 
si ($? != 0) 

SendMsg (E, npstat failed, npstat_errorfile) 
rc= $? 

sinon 

traitement resultfile => Queue <queue_nanne> <instatus> <outstatus> 
<requests> 

return current_param_value=outstatus in (started, stopped) 
condition 1 : 

si (GetDelta(current_obj. DPF_QUEUE_OUTSTATUS, &val) != 0) 
action 1 : 

si (current_parann_value != "started") 

DisplayState (cun-ent.obj, DPF_QUEUE„OUTSTATUS. DPF_QUEUE. 
warning_color, current_param_value) 

SendMsg (W, <queue_nanne> is <current_param_value>) 

sinon 

DisplayState (current_obj, DPF_QUEUE_OUTSTATUS. DPF_QUEUE. 
ok_color, current_param_value) 

SendMsg (W. <queue_name> is <current_param_value>) 

parametre DPF_QUEUE_REQUEST_STATUS 
mesure : 
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npstat -h <uname_node> 1> resultfile 2>npstat_errorfile 
si ($? != 0) 

SendMsg (E. npstat failed. npstat_eiTorfile) 
rc= $? 

sinon 

traitement resultfile => Queue <queue_name> <instatus> <outstatus> 
<requests> 

si (requests > 0) 

res_npshow= npshow -S queue=<queue_name> 2> 
npshow_errorfile* 

si ($? != 0) 

SendMsg (E, npshow failed, npshow__errorfile) 
return rc=$? 

sinon 

traitement res_npshow => nb_active 
si (nb__active = 0) 

return current_param_value=waiting 
sinon return current_param_value=ok 
sinon return current_param_value=ok 
condition 1 : 

si (GetDelta(current_obj, DPF_QUEUE_REQUEST_STATUS. Aval) != 0) 
action 1 : 

si (current_param_value = '^A^aitin9") 

DisplayState (curent^obj, DPF_QUEUE_REQUEST_STATUS, 
DPF_QUEUE, warning__color, current_param_value) 

SendMsg (W. there are sonne requests waiting on <queue__name> 
queue, but none is active) 

parametre DPF_DEVICE_STATUS 
mesure ; 
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npstat -h <uname_node> 1> resultfile 2>npstat_errorfile 
si ($? != 0) 

SendMsg (E. npstat failed. npstat_erTorfile) 

rc= $? 

sinon 

traitement resultfile => Device <device_name> <status> 


return current_param_value=status in (idle_busy, disabled, paperjoad. 
unbound, paper_empty. problem, suspended) 
condition 1 : 

si (GetDelta(current_obj. DPF_DEVICE_STATUS. &val) != 0) 
action 1 : 

si (current_param_value != "idle_busy") 

si (cun'ent_param_value=("problem" ou "suspended")) 

DisplayState (cun^ent^obj. DPF_DEVICE_STATUS. 

DPF_DEVICE, severe^color, current_param_value) 

SendMsg (A, <device_name> device is in abnomnal state 
<current_param_value>) 
sinon 

DisplayState (cun^ent^obj, DPF_DEVICE_STATUS. 

DPF_DEVICE, ok_color. current_param_value) 

SendMsg (W, <device_name> device is <current_parann_value>) 

sinon 

DisplayState (current_obj. DPF_DEVICE_STATUS, 

DPF_DEVICE, ok_color. current_param_value) 

SendMsg (W. <device_name> device is <current_parann_value>) 

Egalement, relativement au module specifique a Oracle, il doit etre, entre autres, permis de controler I'acces aux 
objets pour prevenir tout bloquage ou suspension ("abori") de ['application si cette derniere desire acceder k la base 
ou aux objets Oracle. Certaines informations liees ^ I'espace ("extents", "free list", ...) sont egalement contr6l6es. De 
plus la collecte de m(§triques Oracle est aussi autorisee. Les mesures ne sont effectuees que gtobalement et non sur 
un espace table ("tablespace") ou un processus particulier Cela veut dire qu'il n'est pas possible de mesurer par 
exemple le nombre de blocs alloues pour I'espace table "SYSTEM". Cependant, I'utilisateur peut creer un parametre 
et specifier la commando ^ executor, comme par exemple, 

CREATE_PARAM or71 6. ts_SYSTEM_blocks. ME ASURE=(SPECI F_FILE,'x/y/z.sql'), [TRACE], PERIOD=1 2h, [CON- 
DITION=((# > 320) ACTION=(UNIX_FILE . 'xyy'))]; 

Suit un exemple de mise en oeuvre du module specifique a Oracle : 
Relativement aux parametres et conditions predefinies : 
ORA_GONNECT : faire une connexion "<connect_string>". La valeur du parametre est 0 (OK) ou 2 ("connect" impos- 
sible). Si la connexion est impossible, Taction par defaut est de relancer une fois la base. Choisir les mesures les plus 
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utiles pour repondre aux objectifs du produit : prevention/detection de problemes d'espace ou de performances, aide 
a estimer I'evolution de la Base dans le temps. Choix des ou parmi les mesures suivantes ("source DbaXpert" et "server 
manager"). 

5 - mesures sur I'activite du serveur: 

connected_user_count, session_count, waiting_session_count, current_open_cursors, logical_reads, 
physicaljo, user_commits, recursive_calls. 

mesures sur les fichiers de donnees d'entrees/sorties : 
10 df_physical_reads, df_physical_writes, df_physicaLblock_reads, df_physicaLblock_writes. 

mesures sur la mise au point du cache ("cache_tuning") : 

logicaLreads, ddc_gets, free_buffer_requested, ddc_getmisses, free_buffersjnspected, physicaLreads. 
ddc_get_hitratio, buffer_cache_hltratio. 

15 

mesures sur les transactions : 

active_transactions, rs_gets, rs_waits, redo_writes. redo_blocks_written, userJocks_count, user_rollbacks. 
mesures sur les etats : 

20 cumulated_opened_cursor, parse„count, long_table_scans. short_table„scans, table_fetch_by_rowid, 

table_scan_rows_gotten, memory _sorts, disk_sorts. 

mesures sur les verrous ("latches") : 
latch_gets, latch_misses, latch_hitratio. 

25 

mesures sur les processus ; 

voir v$dispatcher, v$shared server v$process. 

mesures sur les espaces table ("tablespaces") : voir "space monitor". 
30 ORA_ROW_CHAINING : 

Pour chaque table, mesure du nombre de lignes d'enchainement ("row chaining") puis test par rapport a un seuil, 
par defaut, I'agent remonte une alarme vers I'historique du produit. DbaXpert/space monitor est appele et I'alarme TAO 
est configuree avec -s ORA_TA0.sh (script k appeler si alarme, qui envoie une alarme vers I'historique du produit) et 
35 -d 0 (pas de remontee d'alarme vers DB*Control). 

si une condition explicite n'existe pas sur ce parametre : faire "monitor table symptom=(TAO)", 

si une condition explicite avec "IGNORE" sur ce parametre ; ne rien faire, 

40 

si une condition explicite existe sur ce parametre, non combinee avec d'autres conditions : faire "monitor table 
symptom=(TAO, seuil [.hysteresis])", 

si une condition explicite existe sur ce parametre, combinee avec d'autres conditions : faire "monitor table symp- 
45 tom=(TAO, seuil [.hysteresis])" 

acces aux objets : 

paramJdent=HEALTH. Acces aux bases (par SQL connect, la DO string user/pass wd@dbst ring dbc/dbc@T: 
50 or714 est fournie par I'utilisateur). Si la connexion est KO : action ORA_CONN_FAIL et enregistrement dans 

le fichier "actionlog". 

teste que les bases de donnees ne sont pas demarrees en exclusif (par oubli du "DBA"). Le niveau d'alarme 
("info", "warning", "critical") est defini par I'utilisateur. Action "ORA_EXG_MOUNT". Enregistrement dans 
55 "trace_params'*. 

si "ARGHIVELOG". teste que le "process background arch" tourne sinon base de donnees bloquee des que 
les fichiers "redo logs" sont pleins. Action "ORA_ARGH_STOP" et enregistrement dans "trace.params". 


31 


BNSOOCID: <EP 0822498A1J_> 


EP 0 822 498 A1 


detecte et corrige les archives de fichiers "log" saturees. Correction par sauvegarde d'un nombre d'archives 
tel que un seuil d'espace libra est garanti dans le systeme de fichiers. 

surveille les "processes background", verifie que ('instance oracle est stoppee normalement ("normal shutdown") 
si stoppee. 

detecte si SQL*Net est tombe et assure la remise en route. 

detecte si une instance (ses "processes background" et autres) est tombee et assure la remise en route. 

space mgt : il faut prevenir les situations de blocage possible et ne pas s'occuper d'optimiser les performances, 
ceci est traite par "DbaExpert". 

Les blocages peuvent arriver si une table (ou un index, "cluster"", "rollback sgt") a atteint son extention maximale 
("MAXEXTENTS"), si la taille maximum d'un fragment est trop petite pourallouer le prochain "extent", si les fichiers 
de base de donnees ("dbfiles") sont pleins. Action dans ce cas. 

Par "tablespace", taux de remplissage des dbfiles > seuil x ? Si oui, action "ORA_FREE_TS". 

calcule la taille maximum des fragments. Si inferieure a la valeur du prochain "extent" alors action 
"ORA_MAX_FRG" et enregistrement dans le fichier "actionlog". 

comparaison du nombre actuel "d'extents" avec le maximum permis "MAXEXTENTS" (defini a la creation de 
I'objet, clause "STORAGE"). Dans ce cas, I'application utilisant la table sera suspendue ("abort"). II faut pre- 
venir cet incident. Action "ORA__MAX_EXT" si I'objet atteint son "maxextents". Enregistrement dans "action- 
log". 

etat des disques support des fichiers Oracle : une panne disque va se traduire par un return code Oracle (bloc 
corrompu) et seule I'application le recupere. Si detection, il faut au moins le signaler a I'administrateur. 


- ...{ ORA_MAX_FREE_EXTENT_SIZE, object Jdent, tablespacename. 
value_l. value_W, value_C 

! ORA_MAX_EXTENTS, objectjdent. usemame.objectname. {sever_l | 
sever_W | sever_C} 

! ORA_FULL_DBFILES. objectjdent, tablespacename, value_l. value_W. 
value_C 

} 

nombre de transactions oracle par seconde, pour un noeud donne, pour une instance donnee : Affichage. 

Parametre ora_tps, <object_ident>, 
command={SQL,'sqLtx'}. FREQUENCY=30 
DISPLAY={'nombre de TPS ora_simuload'}; 
avec sqLtx : select gets/2 from v$latch where latch#=20. 

condition : si ce taux decroit fortement et que le nombre d'utilisateurs connectes ne decroit pas, alors declen- 
cher une action qui pourrait etre zoom plus detaille de parametres, enregistrement d'informations, sauvegarde 
de fichiers "trace", collecte plus fine, ...) 

nombre moyen de serveurs partages oracle, pour un noeud donne, pour une instance donn6e. Pas d'affichage. 

Parametre ora_shared_srv, <object_ident>, 
command={SQL,'sql_srv SO'}, FREQUENCY=30; 

avec sqLsrv : select count(*) from v$process where program like '%(S0%'; 
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nombre moyen d'utilisateurs oracle connectes , pour un noeud donne, pour une instance donnee. Pas d'affichage. 

Parannetre ora_sessions, <object Jdent>, 
command={SQL;sql_sessions'}, FREQUENCY=30; 
5 avec sqLsessions : select count(*) fronn v$session where status=' ACTIVE' AND lockwait is not NULL; 

distributeur ("dispatcher") : 

Si un distributeur est tres occupe ("delta(v$dispatcher.busy)/delta(t) > 50%") et que le taux d'occupation cpu du 
10 noeud n'est pas trop grand (<80%), alors il faudrait ajouter un distributeur de meme protocole (action autonnatique ou 
recommandation). 

Si le tennps d'attente/nombre de reponses ("v$queue.wait/v$queue.totalq") dans la queue de reponse du distribu- 
teur augmente regulierement et que le taux d'occupation cpu du noeud n'est pas trop grand (<80%), alors il faudrait 
ajouter un distributeur de meme protocole (action automatique ou recommandation ). 
15 Quand oraSIDCurrentConnectedClients = oraSIDReservedConnections, alors les demandes de connexion distri- 

buteur vont vers des serveurs dedies. 

Surveiller le nombre de connexions (moyenne, courante) sur chaque distributeur et sur chaque serveur partage. 
Si oraDispatcherRejectedConnections augmente beaucoup, surveiller oraDispatcherState (BLOCKED, READY). 
Si oraPrespawnedSrvRejectedConnections augmente beaucoup, surveiller oraPrespawnedState (BLOCKED, 
20 READY). 

oraPrespawnedSrvProcessorlD est le process ID : faire le lien avec la consommation ressources systeme. 
entrees/sorties : 

si mauvaise repartition des entrees/sorties sur les commandes ("drives"), au niveau systeme : alors regarder 
25 la repartition des entrees/sorties par instance et sur les fichiers de base de donnees. 

De meme, relativement au module specifique a Tuxedo, il doit etre, entre autres, permis de surveiller I'etat 
des applications Tuxedo, des serveurs, des queues, du reseau en utilisant la commande "tmadmin psr, psc, pq, 
print_net". Pour Tuxedo, les sen/eurs administratifs ("BBL", "DBBL", "Bridge") et les applicatifs sont survetlles. 
L'acces aux differents noeuds de I'application Tuxedo (partitionnement du reseau) ainsi que les queues utilisees 
30 par I'application sont verifies. Si Tapplication appelle des transactions d'une machine determinee, ladite machine 

determinee est verifiee. 

Suit un exempte de mise en oeuvre du module specifique a Tuxedo : generation dans le fichier "objstate", via 
la fonctlon de base "DisplayState" : 

35 TUXEDO:<severityJevel>:<appname>:NIL:<global_id> 

TUX_MASTER:<severityJevel>:<node>:<appname>:<tux_fatherJd> 
[TUX_NODE:<severityJevel>:<node>:<appname>:<tux_fatherJd>]... 
[TUX_QUEUE:<severity_level>:<qname>;<appname>:<tux_father_id>]... 
[TUX_DOMAIN:<severity_level>:<domain_name>;<appname>:<tux_father_id>] 

40 


avec 

la ligne TUXEDO est generee en fonction des lignes filles TUX_MASTER, 
45 TUX_NODE... 

TUX_NODE : une ligne par Imid autre que master. 
TUX_QUEUE : une ligne par OS PACE (tbc). 
TUX_DOMAIN : une ligne par domaine. 

50 - parametre TUX_xx_STATUS 

nombre de demandes de service (transactions) par seconde. pour un noeud donne, pour une application Tuxedo 
donnee : cumuler le #RqDone des serveurs autres que "BBL", "DBBL". "BRIDGE", "TMS*". Affichage. 

55 

Parametre SVC_<node>, <object_ident>, 
command={SHELL/tmadmin_srv node'}. FREQUENCY=30 
DlSPLAY={'nombre de TPS simuload'};; 


33 


BNSOOCID: <EP_0822498A1J^ 


EP 0 822 498 A1 


avec tmadmin_srv : tmadmin ...psr + filtre sur noeud + delta (#RqDone) par rapport h la derniere coHecte. 
division par la frequence. 

nonnbre nnoyen de clients actifs, pour un noeud donne, pour une application Tuxedo donnee. Pas d'affichage. 

Parametre CLT_<node>, <objectJdent>, 
command=:{SHELL/tnnadnnin_dt node'}, FREQUENCY=30; 

avec tmadnnin_clt:tmadmin...pclt + filtre sur noeud + nonnbre de lignes client occupees (BUSY). 

pour un serveur donne sur un noeud donne : le nonnbre nnoyen de requetes en queue, par queue. Le faire pour 
tous les serveurs. Pas d'affichage. Permet de savoir si le nombre de serveurs dupllques est adapte. Si la moyenne 
de requetes en queue est > 1 0 ( exennple 1 0 est un peu plus grand que le nonnbre moyen de clients actifs deman- 
deurs d'un service du serveur) alors action pour ajouter un serveur jusqu'a max). 

Parannetre SRVREQ_<srvnanne>_<node>, <objectJdent>. 
command={SHELL/tmadmin_srvreq node srvname'}, FREQUENCY=60 
CONDITION_S=:{&1 > 10}; 

avec tmadnnin_srvreq : tmadnnin ...pq + filtre sur srvname + champ Queued. Cumuler le "Queued" sur les n 
serveurs sur le noeud, divisor par le nombre de queues. 

avec Taction : 

SRVREQ_<srvname>_<node> : 

si cpu <node> < 80% then tmboot -s <srvname> -i num 

(num calcule avec tmadmin psr pour connaitre les srvid actuels). 

pour un serveur donne sur un noeud donne : le nombre moyen de serveurs appiicatifs sur un noeud donne, pour 
une application Tuxedo donnee. Pas d'affichage. A correler avec la taille de la queue. 

Parametre SRVNB_<srvname>_<node>, <objectJdent>, 
command=:{SHELL,'tmadmin„srvnb node sn/name'}, FREQUENCYr:60; 
avec tmadmin_srvnb:tmadmin...psr + filtre sur srvname. 

pour un service donne sur un noeud donne, pour une application Tuxedo donnee ; le nombre de requetes faites 
par quart d'heure. Le faire pour tous les services. Pas d'affichage. Pour mesurer I'utilisatton des services. 

Parametre SVCDREQ_<svcname>_<node>, <object_ident>, 
MEASURE={UN1X_FILE ,*tmadmin_svcdreq node svcname'}, PERIOD=900 ; 

avec tmadmin_svcdreq : tmadmin ...psc + filtre sur svcname + delta (#Done) par rapport a la derniere collecte, division 
par la frequence. Cumuler le #Done si le service est sur n serveurs sur le noeud. 

L'administrateur Tuxedo affecte un poids aux services et il s'en sert pour I'equilibrage de charge. Ces poids ne 
sont pas forcement bien choisis, surtout dans le temps. On peut prevoirr que ces poids soient ajustes automatiquement 
en fonction de criteres admin ist rate ur. 

Aussi, relativement au module specifique a "xcp2", il doit etre, entre autres, permis d'utiliser la commande "/usr/ 
xcp2/up/dac_lu62 -a DSPSESST" pour connaitre I'etat du groupe ("pool") "xcp2". 

Enfin, relativement au module specifique "systeme", il dolt etre, entre autres, permis de controler et mesurer le 
temps cpu, I'espace disque, les entrees/sorties, la memoire, le debit telecom, le nombre d'utilisateurs, la pagination, 
le reseau, etc.. II est ainsi par exemple possible de mesurer le taux d'occupation cpu par seconde, avec afftchage par 
defaut, ou le taux d'entrees/sortles par seconde, ou encore d'identifier les processus les plus consommateurs de cpu 
et de les collecter pour reatiser une analyse autonome ("offline", tbc). 

Pour conclure, suivant le present proced^ de surveillance, I'utilisation d'agents autonomes permet de s'assurer 
du bon fonctionnement des applications surveillees sur I'ensemble des noeuds k I'aide d'un traitement decisionnei 
autonome et efflcace applique au plus pr6s des objets k traiter, de faire remonter lorsque c'est n6cessaire et ceci tr^s 
rapidement, des noeuds ^ surveiller vers le noeud d'administration, les informations utiles et de lancer de mani6re 
automatique des actions sur certaines conditions ou de conseiller eventuellement une action. De cette maniere, une 
surveillance efficace des objets fonctionnant sur la plurality de noeuds est assuree et une augmentation significative 
des performanvces est obtenue du fait de la capacity d'ind6pendance offerte dans leur travail aux divers agents auto- 
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nomes, le precede ici applique permettant de mesurer des parametres specifiques de chaque objet, de tester des 
conditions sur ces parametres relativement a des seuils puis d'executer une action pour prevenir d'un probleme, pour 
reconfigurer ou corriger. Des mesures sont collectees pour realiser une analyse en temps differe dans le but d'un 
examen statistique de I'activite surveillee. Ces mesures collectees concernent tous les types d'objets ^ surveiller, par 

5 exemple ici des instances telles que des bases de donnees comme Oracle, Informix, les applications comme Tuxedo, 
differentes ou une quelconque machine. I'impression distribute (DPF), etc. . Egalement, I'aspect synthetique d'un objet 
global defini de maniere generique, offre une tres grande liberie d'action et autorise I'exploitation efficace de la notion 
d'arborescence avec une grande precision relativement a revolution des grains de visualisation obtenus. Des corre- 
lations peuvent etre realisees entre plusieurs mesures differentes, en particulier, entre divers types d'objets, c'est-a- 

10 dire qu'une correlation intertype est ainsi avantageusement proposee. Ce procede est en outre portable sur differentes 
plate-formes, du fait de sa totale independence relativement a son environnement d'execution, la visualisation se 
faisant au moyen d'une interface graphique propre audit procede. Ce procede est de plus prevu pour autoriser tout 
interfagage avec un quelconque systeme d'administration pour offrir a I'utilisateur une administration integree, les 
agents autonomes accedant aux differentes informations a travers les protocoles standards existants. 

IS 

R vendications 

1. Procede de surveillance d'une pluralite de types d'objets sur une pluralite de noeuds comprenant un noeud d'ad- 
20 ministration dans un systeme informatique, caracterise en ce que, la sun/eillance est configuree puis diffusee de 

maniere filtree k partir du noeud d'administration vers des agents autonomes, un agent autonome etant installe 
sur chaque noeud a surveiller pour, en offrant une correlation intertype, soit traiter au plus pres les differents types 
d'objets ou ensemble d'objets d'un domaine appele objet global defini de maniere generique, soit remonter des 
informations a visualiser vers interface graphique du noeud d'administration, chaque agent comportant une plu- 
25 ralite de modules specifiques propres aux differents types d'objets ou k un domaine particulier, chaque module 

specifique mesurantdes parametres statiques et dynamiques, particuliers autyped'objetqu'il surveille etcollectant 
lesdites mesures, testant des conditions sur lesdits parametres relativement a des seuils predefinis et declenchant 
eventuellement des actions associees auxdites conditions testees, les parametres, les conditions et les actions 
etant modifiables par I'utilisateur du noeud d'administration. 

30 

2. Procede de surveillance selon la revendication 1, pour I'application duquel le noeud d'administration comporte 
entre autres, une interface graphique utilisateur pour la visualisation des objets selectionnes et I'affichage de cour- 
bes de valeurs de parametres, un fichier de configuration qui contient I'ensemble des configurations des objets 
avec la description desdits objets de meme que I'ensemble des parametres predefinis statiques ou dynamiques, 

35 ce fichier etant analyse et dynamiquement modifie ou complete, des fichiers d'etat des noeuds a surveiller ainsi 

que les fichiers d'affichage des parametres, les parametres mesures etant stockes dans un fichier d'analyse pour 
permettre leur affichage par I'intermediaire de I'interface graphique. 

3. Procede de surveillance selon la revendication 1 ou 2, pour I'application duquel I'agent autonome installe sur 
40 chaque noeud a surveiller se compose principalement d'un agent generique en relation avec une pluralite de 

modules specifiques chacun propre k un type d'objet ou a un domaine particulier, de fichiers contenant les fonctions 
de base utilisees, chaque noeud a sun/eiller possedant de plus ses propres fichiers de parametres, de conditions 
et d'actions associees pour controler sa propre surveillance et ainsi autoriser le traitement au plus pres des diffe- 
rents types d'objets en mesurant les parametres, en evaluant les conditions et en langant les actions liees aux 
45 conditions et ceci pour tous les objets decrits. 

4. Procede de surveillance selon les revendications 2 ou 3. pour I'application duquel, lorsqu'une condition non liee 
a un parametre porte sur un ou plusieurs parametres et done sur un ou plusieurs objets, ladite condition est traitee 
sur le noeud d'administration par un agent generique qui traite les conditions sur plusieurs noeuds, cet agent 

50 generique "d'administration" langant Taction sur le noeud d'administration. 

5. Procede de surveillance selon la revendication 4, pour lequel le traitement de I'agent generique "d'administration" 
se fait de la maniere suivante: 

55 - lecture de son fichier de configuration, analyse syntaxique et semantique. 

fusion du fichier de configuration fourni par le noeud d'administration et du fichier de configuration fourni par 
les modules specifiques, 
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envoi du fichier de configuration resultant a chaque agent en filtrant relativement aux objets a surveiller sur 
le noeud et en tenant connpte des problemes inherents aux noeuds en panne ou aux noeuds prevus pour la 
sauvegarde des donnees d'un noeud en panne sur un autre noeud. 

Precede de surveillance selon la revendtcation 5. pour lequel le traitement de I'agent generlque d'un noeud a 
surveiller se fait de la maniere suivante : 

lecture de son fichier de configuration, seuls les objets locaux a ce noeud etant traites, 

construction de la table d'objets, 

construction de la table de configuration des parametres, 
construction de la table des valeurs de parannetres : 

* chaque parametre de chaque objet ayant au moins un emplacement pour mettre sa/ses valeur(s), le 
nombre d'emplacements a reserver pour ce parametre de cet objet etant calcule, 

construction de la table des conditions multiples, 

fourniture des fonctions de base k Tusage des modules specifiques pour certaines et pour les actions externes 
pour d'autres, 

lancement des modules specifiques : 

* certains modules specifiques possedant un traitement propre, alors que d'autres sont regroupes dans un 
seul traitement, 

* seuls les modules ayant un objet a surveiller etant lances, 

configuration d'un service de surveillance de fichiers de maniere a permettre le traitement de I'exploration des 
fichiers de journalisation de tous les objets decrits, 

evaluation de chaque condition multiple, avec sa periode : 

* chercher les valeurs des parametres dans la table des valeurs de parametres ou via une fonction de base, 

* si la condition multiple est verifiee, lancer Taction interne ou externe, 

surveillance reguliere du bon fonctionnement des modules specifiques, envoi d'un parametre special et attente 
de la reponse. 

Precede de surveillance selon la revendication 6, pour lequel le traitement d'un module specifique se fait de la 
maniere suivante : 

exploration de la table de configuration des parametres en ne traitant que ses propres objets ; 

* parametres deja tries par periode croissante, 

* pour chaque parametre de chaque objet, selon la periode : 

faire la mesure en utilisant la commande interne (parametre predefini) ou externe, la mettre dans la 
table des valeurs de parametres, 

si une analyse est effectuee, mettre la valeur dans le fichier d'analyse global de I'agent autonome, 
si un affichage est demande, afficher la valeur ou I'etat, 
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evaluer la condition simple, si elle existe, lancer Taction (interne ou externe) si la condition est vraie, 

traitement des dennandes inopinees de mesure en tennps reel de parametre. 

Precede de surveillance selon la revendication 7, dans lequel, lorsqu'une action, predefinie ou externe demande 
la valeur d'un parametre d'un objet sun/eille par un autre noeud que le noeud ou est executee Taction, la fonction 
de base qui demande la valeur transfere cette demande au noeud d'administration qui la dirige alors sur le noeud 
adequat alors que la valeur est retournee en sens inverse. 

Precede de surveillance selon la revendication 8, dans lequel, une des fonctions de base presentee est prevue 
pour ramener sur le noeud d'administration les fichiers de journalisation de parametres ainsi que ceux d'actions 
de chaque noeud sufveille, pour Tanalyse independante realisee par le noeud d'administration. 

Precede de surveillance selon Tune des revendications precedentes, pour lequel le traitement d'un parametre est 
effectue de la sorte : 

si le parametre est valide et la periode determinee alors la mesure est executee, 

si une condition sur un parametre existe et que le parametre est valide, alors la condition est evaluee 

Precede de surveillance selon Tune des revendications precedentes, pour lequel le traitement des actions est 
realise comme suit : 

Tagent generique et les modules specifiques demandent a lancer une action (predefinie ou feurnie par Texte- 
25 rieur), 

toute action regoit des arguments qui representent le contexte qui declenche Taction : 

dans le cas d'une condition multiple, Tidentifiant d'objet, Tidentifiant du parametre, le numero de la cendi- 
30 tion, 

dans le cas d'une condition simple, la valeur mesuree du parametre, son seuil et son hysteresis, Topera- 
teur. 
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